RE: Eliminating static roots from gcj

["Boehm, Hans" <hans dot boehm at hp dot com>]

> -----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.

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.

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

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

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

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.

> 
> Clearly, ceasing to scan shared objects conservatively is a 
> big advance for gcj, but I'd prefer it not to be accompanied 
> by regressions in code quality.
> 
> Andrew.
> 
Agreed.

Hans