[gambit-list] Gambit's Linking Model

Guillaume Cartier gcartier at jazzscheme.org
Wed Jun 13 21:22:56 EDT 2007

schemeway at sympatico.ca wrote:
> Guillaume,
> would it be possible to simply load the whole application at once, and then 
> only "patch" the application with all the interpreted classes? If no class 
> has been modified, then you get a fast startup time.
> Maybe this is too simplistic. If you have side-effects in "static" portions 
> of your classes (like in Java), this may not work, of course. But you know 
> better than me.
> Dominique

Yes. You're right for the static side effects. And also, suppose a file 
F with (class F extends Window ...) that became (interface F extends (I 
J) ...)! Imagine the challenge to undo all the runtime initializations 
done by class F!

Note that after thinking about the problem, I could probably do my own 
delaying by doing in essence something like

(define x #f)
(define y #f)
(define z #f)

(register-class-initializer 'F
  (lambda ()
    (set! x ...)
    (set! y ...)
    (set! z ...)))

One thing that is annoying with that, is that Gambit won't be able to do 
many optimizations because of my code mutating all my variables.

>> Let me try to elaborate.
>> For some background, I am in the process of porting the C++ Kernel of
>> JazzScheme (a Scheme like programming language) to Gambit.
>> I'll talk in terms of classes as in Jazz the association to source code
>> is done by class names but it is not essential in nature.
>> One essential feature of JazzScheme is the following:
>>   - Lets say I build an application with all its classes compiled into
>> one executable. This is very important as some classes are so lowlevel
>> than using many of them interpreted can really slow down the application
>>   - While running this application, I decide to make a live change to
>> the code of lets say class F by evaluating some part of the source code
>> file lets say F.jazz (this is possible as the function that was compiled
>> is replaced by a new interpreted one and compiled and interpreted code
>> can freely mix as in Gambit)
>>   - Here's the catch... Next time I launch the application, when loading
>> class F, Jazz will first check the modification time of F.jazz and
>> because it is more recent than the modification time of the internal
>> compiled version, will load the class from the source code making in it
>> unnecessary to always rebuild applications. This is possible because,
>> even in the executable, code has to be explicitly loaded. In other
>> words, the semantics of compiled and interpreted code is the same in
>> regards to 'load'. This is one thing I do not see how to do with Gambit
>> and that cannot really be solved by packaging into separate modules of
>> related files.
>> PS: Marc: I was thinking how I guess Gambit must do some linking work
>> when loading the compiled C code representing a .scm file to make its
>> symbols available to the runtime. Couldn't this linking job be separated
>> so that by default it is done automatically but it can also be put in a
>> mode where it needs to be explicitly called?
>> Guillaume
>> Christian Jaeger wrote:
>>> FWIW, my thoughts:
>>> You want to be able to load code selectively (on demand, not on startup,
>>> if I understand correctly), but then you don't want to do it because of
>>> loading speed concerns--that's sort of contradicting itself, isn't it? 
>> :)
>>> With my chjmodule stuff, I'm going the .o1 file route; the programs I've
>>> been writing up to now are loading maybe 20 or 30 such object files
>>> only, not thousands. (It actually *is* a slow process with chjmodule,
>>> but not because of the loading of the object files themselves but
>>> because of the aliasing (copying) of the identifyers to the other
>>> namespaces; I'm using eval (like (eval `(define ,id1 ,id2))) for this
>>> and that's slow (I'm sure that can be improved, I just haven't 
>> bothered).)
>>> If loading speed or the number of modules is an issue, maybe you could
>>> group together modules which are usually loaded together (by using, say,
>>> |include|), maybe reducing the 1000 items to a few hundred or less?
>>> (Gambit can also do a better job optimizing when you group together code
>>> (block compilation with inlining).) Dunno about zipping, one of the good
>>> things of shared object files is that they are mmap'ed into the process
>>> so they are shared by multiple independent processes; this is lost if
>>> each process extracts the objects to private memory.
>>> What's the reason why you can't live with the code being already loaded
>>> at launch time?
>>> Christian.
>> _______________________________________________
>> Gambit-list mailing list
>> Gambit-list at iro.umontreal.ca
>> https://webmail.iro.umontreal.ca/mailman/listinfo/gambit-list
> _______________________________________________
> Gambit-list mailing list
> Gambit-list at iro.umontreal.ca
> https://webmail.iro.umontreal.ca/mailman/listinfo/gambit-list

More information about the Gambit-list mailing list