RE: Eliminating static roots from gcj

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

>  > >
>  > > 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.
The problem is that this can run with other code stopped at arbitrary
places.  If it stops with a class half loaded, presumably the constant
pool may have been incompletely initialized, and only one or none of the
data and size fields may have been set?  And we have to worry about
atomicity of assignments to the data and size fields, and whether the
compiler might move one of the assignments?
> 
>  > 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.
That actually wasn't very high up on my list of priorities.  It's
trivial to increase the size of the static root table.  I don't think
that even a factor of 10 would have a huge impact on footprint.  It
would also be fairly easy to make the size settable at process startup.
Dynamically reallocating the data structure is possible, but since it
tends to get repopulated at each GC in order to account for newly loaded
libraries, it risks getting stuck in an out-of-memory situation that you
can't recover from sufficiently to throw an exception.
> 
>  > 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.
>