[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