[gambit-list] Gambit's Linking Model

Guillaume Cartier gcartier at jazzscheme.org
Wed Jun 13 20:04:21 EDT 2007


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.
>
>
>
>   




More information about the Gambit-list mailing list