schemeway@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.
Guillaume
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@iro.umontreal.ca https://webmail.iro.umontreal.ca/mailman/listinfo/gambit-list
Gambit-list mailing list Gambit-list@iro.umontreal.ca https://webmail.iro.umontreal.ca/mailman/listinfo/gambit-list