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

Boehm, Hans hans_boehm@hp.com
Thu Apr 12 16:09:00 GMT 2001


> -----Original Message-----
> From: Corey Minyard [ mailto:minyard@acm.org ]
>
> The only advantage I can see to a _Jv_ function is you could make it
> weak and then be able to use different GCs with the same GCJ library.
> That's convenient for me, but I'm not sure of the general benefit.
> You would have to handle all the accurate scanning of object and
> arrays and initialization, as part of the "generic" interface, too.
> That would be my ideal, but it would probably take some time to get
> there and I'm not sure if it's worth it.
I'm not sure how your collector currently scans objects.  I'm trying to
isolate the collector library from libgcj sufficiently that the libgcj code
doesn't need to include GC private header files and hence no longer depends
on offsets in GC-private data structures.  If this all works, eventually
different versions of our GC should work with the same libgcj.  So there
will be more of a well-defined interface between the two.  I suspect that a
fundamentally similar collector might be able to use the same interface, but
you'd be stuck with the same object layout descriptors, etc.  And the
interface probably isn't sufficient for something like a mostly copying
collector.

I don't have a clear picture how much it would cost to generalize the
interface.  My guess is that separating the current GC from libgcj to even
this small extent is likely to be feasible only because the GC traversal
rarely needs to call back into libgcj, and thus we can afford to add a
little overhead there.

I don't see a problem with including weak _Jv_ symbols in our GC library by
default.  It might be easier to go that route.
> 
> > 
> > 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.
> 
> This window doesn't seem that important.  As long as the allocating
> code installs the vtable pointer first, the GC could ignore the object
> if its vtable pointer is NULL.  Since no valid pointers should be in
> the object at that point in time, that should work fine.  Am I missing
> a race here?  This is how the arrays currently work.
After thinking about this some more, I agree, though I would want to think
about it more before changing anything.  You do need to be careful that the
compiler back end doesn't reorder the vtable store with a pointer store into
a field of the object.  (I think hardware reordering doesn't matter here,
since the thread will be stopped during tracing.)  In my case, if you
allocate from a shared free list using a lock, you would end up writing the
vtable field twice, once with zero, and then with the real value.  But I
think that in the thread-local allocation case even that isn't necessary, so
long as you write the vtable pointer before the next allocation call.

Should we consider passing just the size?  That wouldn't give the allocator
any opportunity to handle different types differently.  It still seems
marginally cleaner to me to pass the vtable, given that at least in my case,
the collector eventually looks at the mark descriptor stored there.

This brings up the issue of pointerfree objects.  They're very special to
our collector, in that they don't have to be touched during tracing, which
saves memory and potentially disk traffic.  Assuming hash synchronization, I
suspect they consitute a significant fraction of objects in some
applications (e.g. the SPEC raytracing benchmark?)  It would be nice to have
the compiler issue a different allocation call for those.  This is the only
case I can think of in which I would otherwise consider interpreting parts
of the vtable 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?
> 
> If I have a more efficient way, I'll probably use it.  I'm not sure
> what you mean by "front end" in this context.  The interface is
> probably fine, although it limits GCJ to only having one type of
> object marking function.
I meant the gcj front end, i.e. a parameter to gcj itself that specifies the
parameters passed to the allocator.



More information about the Java mailing list