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

[Tom Tromey]

>>>>> "Hans" == Boehm, Hans <hans_boehm@hp.com> writes:

Hans> I'd like to move in a slightly different direction.  I'd like to
Hans> see gcc generate code that calls GC_gcj_malloc directly in most
Hans> cases, at least for non-embedded applications.

This won't be a problem.

Hans> 2) Checks if a finalizer needs to be registered, and does so if
Hans> necessary.  This is a very expensive (5 + memory references?)
Hans> test for something that I believe is completely statically
Hans> known.

I agree it is statically known.

Hans> A disadvantage of this change is that it would create a direct
Hans> dependency from gcj generated code to the GC library.

This isn't actually as big a problem as you might think.

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.

What we can do here is make the GC function names a command-line
option to gcj.  Then we drop the appropriate option into libgcj.spec.
That lets us keep all the GC-related configury code close together in
libgcj, without having it spill over into gcj itself.

Tom