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

[Jeff Sturm]

On 12 Apr 2001, Tom Tromey wrote:
> Jeff> 1) If I have two shared libraries, both compiled with compatible
> Jeff> releases of gcj but targetted to different GC libraries, is
> Jeff> there any hope of loading them both into one process image
> Jeff> (i.e. running two GC systems concurrently)?
> 
> I'm not sure I really understand the question.

I'm trying to understand possible drawbacks of tailoring the frontend for
specific GC libraries.  If gcj generates calls to GC_gcj_malloc etc. _and_
an alternative GC becomes widely used with gcj, there is a chance someday
people will be faced with object libraries that cannot be loaded together.

> Right now I think the answer is `yes', because all the GC calls are
> made through _Jv_ wrappers.  We assume a conservative GC all over the
> place, so in many other ways these two GCs would have to be very
> similar.

Right now, yes.  The scenario I brought up isn't likely today because:

a) the current GC interface is mostly generic
b) only boehm-gc is widely used with gcj
c) nobody is distributing java code in native form only, such that
it cannot be recompiled

There are good reasons to change a) and other collectors already exist.  I
hope that anyone who chooses to distribute native java objects will
include source code (or at least class files) permitting recompilation,
but since the libgcj license permits non-GPL use we cannot count on it.

> Jeff> 2) If someone really wants pluggable GC (along with somewhat
> Jeff> reduced efficiency), would it be practical to define a "generic"
> Jeff> GC interface for this purpose?
> 
> We've pretty much done this already.  The problem is that this is
> slow.

It's a tradeoff.  If speed were all that mattered, nobody would build
shared libraries anyway, due to the overhead of PIC and the PLT, etc.

> Also, suppose some day we were to implement write barriers in the
> compiler.  In this case the write barriers would be compiled into the
> code.  For efficiency these would have to be GC-specific.

I suppose they could also be done through a portable interface at some
cost in runtime efficiency.

I'm not at all opposed to GC-specific interfaces in the frontend.  A
generic interface may still be a worthwhile goal however, and there are
those who might choose it if it were a compile-time option.  (Maybe I'm
stating the obvious, I don't know.)  Someday soon libgcj will be widely
distributed with GNU/Linux distributions, and then maintaining a stable
ABI becomes important.

Jeff