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

["Boehm, Hans" <hans_boehm at hp dot com>]

> -----Original Message-----
> From: Jeff Sturm [mailto:jsturm@one-point.com]
> 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
> concurrently)?
> 
> I'm thinking the answer is "no", but just thought I'd ask.
I also think the answer is "no".  If you wanted to make the answer "yes",
you'd need a fairly elaborate protocol between the two collectors to handle
pointer chains that cross from the heap manged by one GC to the other.
> 
> 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.
> 
I would be inclined to make direct calls into the GC a configurable option,
so that you can still go through _Jv_AllocObject if you desire (or probably
if you want to use JVMPI).  I think that gets you this level of
compatibility, assuming both collectors can live with the same generated
code, which I suspect greatly restricts the space of possibilities.  (As far
as I know, the only way to currently get a write barrier is with virtual
memory techniques.  That means generational or incremental collection
requires virtual memory, and you only get update information at coarse
granularity.  And you're presumably limited to a conservative stack scan.)

Hans