RE: Eliminating static roots from gcj

[Andrew Haley <aph at redhat dot com>]

Boehm, Hans writes:
 > > -----Original Message-----
 > > From: Andrew Haley [mailto:aph@redhat.com] 
 > > There are (at least) two possible ways to improve this.
 > > 
 > > 1.  Allocate every instance of Class in the same memory block as its
 > >     constant pool.  Then, accesses to fields in Class and constants
 > >     can be done as indexes from the same base pointer.  This is
 > >     potentially tricky, because the compiler does not know the size of
 > >     instances of Class, and so constants would have to be at negative
 > >     offsets from the start of the object.  Would this be possible with
 > >     finalization and locking?
 > This sounds hard because class references would be at variable
 > displacements into the heap objects representing the class.  The
 > collector can deal with this if you either globally enable interior
 > pointer recognition, or if you register a fixed set of small object
 > offsets that are considered valid.  Neither alternative looks
 > appropriate here.

OK.

 > The hash synchronization code shouldn't care; you're really
 > synchronizing on a (suitably aligned) address, not necessarily a heap
 > object.  And I think the sync-pointer-based code should also be OK.
 > > 
 > > 2.  When scanning an instance of class, do:
 > > 
 > >     GC_ptr p = klass->constants.data;
 > >     if (! GC_base (p))
 > >        for (int i = 0; i < klass->constants.size; i++)
 > > 	   /* Mark klass->constants[i]  */
 > > 
 > >     If we do this, we can go back to the same code generation sequence
 > >     as before.
 > This again introduces funny races with partially constructed classes,
 > which I'd prefer to avoid.

OK.  I'm not sure that I can immediately see what races you mean, but
I'll think about it.

 > Are we trying to scan the constant pool itself less conservatively?

No.  Well, it would be nice, but it's not my goal at the moment.

 > Can we somehow allocate the constant pools statically in a way that the
 > GC can find them, ideally in separate sections?

Sure, but I really don't want to do that because a perennial problem
with gcj is overflow of the static root table.  It's a sub-goal of
this project to eliminate static root registration wherever possible.

 > If not, I think my next choice would be to either 
 > 
 > a) maintain a, possibly lock-free, list of constant pools, and to
 > have the collector look at that list, or

OK, I can see how that would work.

 > b) to use your approach, but with the collector acquiring a lock
 > that is also held when classes are constructed, so that it can't
 > see a partially constructed class.  That might be slightly tricky
 > on the class loading side, since you can't hold that lock while
 > allocating.

That sounds tricky.  

Thank you, you've given me some ideas to think about.

Andrew.