[gambit-list] Gambit's Linking Model
gcartier at jazzscheme.org
Wed Jun 13 21:22:56 EDT 2007
schemeway at sympatico.ca wrote:
> 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.
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)
(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?
>> 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
>>> 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?
>> Gambit-list mailing list
>> Gambit-list at iro.umontreal.ca
> Gambit-list mailing list
> Gambit-list at iro.umontreal.ca
More information about the Gambit-list