[gambit-list] Gambit's Linking Model

schemeway at sympatico.ca schemeway at sympatico.ca
Wed Jun 13 20:48:31 EDT 2007


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

>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





More information about the Gambit-list mailing list