Re: Guile Startup Time Suggestion

[Andrew Archibald <aarchiba@calum.csclub.uwaterloo.ca>]

John Tobey <jtobey@channel1.com> writes:

> Ah, I think you are referring to dynamically-loaded code which
> interacts with the scheme interpreter (registers smobs, stores objects
> in the symbol table, etc.)  I can see how that wouldn't go well with
> an unexec'ed binary.  The library would be loaded at a different
> address, and certain types of pointers would become invalid.

No, it's not just that; I ran into it when I linked -lqt dynamically
(for example), or libreadline.  I think it's that they are getting
mmap'ed at different locations, so the pointers (to the functions) are
stale. 

> But presumably, this doesn't affect libraries (such as libc) that were
> linked with the bare guile the way X11 and the rest are linked with
> emacs.

It seems to.
 
> Under my plan, you would have to link your C modules together with the
> core into a single dynamic library, then unexec it.  You'd have a
> different (large) lib.so for each interpreter-state you wish to
> freeze.  The standard libguile.so would have boot9 loaded, for
> example.

That would be good --- but better would be to have libboot9.so;
something along the lines of scheme48's separate heaps. 

> It's not as modular as it could be, but improvements would involve
> merging symbol tables and the like, which I don't know how to do.

Generally this requires some of the same things as copying GC, which
is impractical in guile.  I don't know if it can be resolved.

Andrew