dynamic library cost (was RE: libtool, java woes)

Jeff Sturm jsturm@one-point.com
Thu Apr 12 11:47:00 GMT 2001

On 12 Apr 2001, Tom Tromey wrote:
> We've already decided, long ago, that the GC would not be dynamically
> pluggable.  That is, we're allowed to require a recompile if the GC
> implementation changes.

That's probably fine for current gcj users.  But in the real world, few
users actually  recompile packages, and if gcj is successful the ABI
issues will be increasingly important.  So I'm wondering...

1) If I have two shared libraries, both compiled with compatible releases
of gcj but targetted to different GC libraries, is there any hope of
loading them both into one process image (i.e. running two GC systems

I'm thinking the answer is "no", but just thought I'd ask.

2) If someone really wants pluggable GC (along with somewhat reduced
efficiency), would it be practical to define a "generic" GC interface for
this purpose?  That would leave the choice up to the package maintainer.

Suppose we had two GC libraries available today, named "boehm" and
"copying".  You could require that these two cannot be mixed freely, but
either could be mixed with a "generic" which would use whatever GC is
loaded at runtime.


More information about the Java mailing list