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

[Corey Minyard]

Remember that at least two others use different GCs with GCJ.

What might be nice would be an interface that any GC could implement
that was divorced from any particular GC.  Something like POSIX (but
hopefully a better design that POSIX).

-Corey

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

> I'd like to move in a slightly different direction.  I'd like to see gcc
> generate code that calls GC_gcj_malloc directly in most cases, at least for
> non-embedded applications.
> 
> In 3.0,the allocation path is _Jv_AllocObject (prims.cc) -> _Jv_AllocObj
> (boehm.cc) -> GC_gcj_malloc (GC library).
> 
> In my version _Jv_AllocObj is simply an inlined call to GC_gcj_malloc, so
> this path is a little shorter, but still too long.
> 
> _Jv_allocObject currently does the following:
> 
> 4) It calls _Jv_AllocObj (which does nothing but call GC_gcj_malloc).
> 
> A disadvantage of this change is that it would create a direct dependency
> from gcj generated code to the GC library.  But I suspect that's already
> implicitly there, since another GC library would probably need a compiler
> write-barrier, etc.
> 
> I'm trying to generalize the GC library, so that a single binary could be
> used for Java, C, ObjC, etc.  So I would like to avoid replicating it in
> libgcj.  It may still  make sense to replicate the top level routines, if
> there's a clean way to do that.
> 
> Hans
>