dynamic library cost (was RE: libtool, java woes)
Thu Apr 12 10:26:00 GMT 2001
[This is very specific to the gcj collector interface and is no longer going
to the general gcc list.]
Using libgcj.spec to specify the allocation function name seems slightly
cleaner than having the collector export a _Jv_ function. Having the
collector export such a function would violate its (self-imposed) naming
rules, and thus could conceivably (with 0.0000001 probability) result in a
naming conflict with another client.
The harder question is: What should the parameters be? I would argue that
for a complete, multithtreaded, not-fully-conservative implementation, the
collector has to install the vtable pointer, or some other piece of
information derived from the class. Otherwise you will end up with a
window during which a heap object won't have type information. This argues
that either the class or the vtable pointer must be passed along with the
size. The original _Jv_AllocObj interface passed the class. GC_gcj_malloc
uses the vtable.
I'm not sure that either is always right. If the collector is gcj specific,
the class might be more convenient. If the collector is not gcj specific,
the vtable makes a lot more sense, since that way the collector needs to
know less about gcj data structures, and can just put the vtable argument
directly in the object. The collector shouldn't have to know how to map a
class to a vtable pointer. The same mechanism is likely to be useful for
multiple language runtimes. It's probably also cheaper to go with the
vtable, since it avoids a dereference in the allocator.
The question then becomes: Can everyone live with the GC_gcj_malloc
interface? (The parameters are currently (size, vtable), in that order.)
Or do we need another parameter to the front end? Or is there a clean and
easy way to supply some sort of template for the call? Or will the other
collectors continue to go through _Jv_AllocObject, so that it suffices just
to turn this mechanism off?
> -----Original Message-----
> From: Tom Tromey [ mailto:email@example.com ]
> We tried to do this with the _Jv_ functions. I guess one could argue
> that the Boehm GC could simply rename the functions it exports.
> Passing the name of the allocation function to gcj via libgcj.spec
> seems like a reasonable approach to me, though. That way each GC gets
> to keep its exported namespace relatively clean, but we don't really
> lose much in terms of maintainability.
More information about the Java