Eliminating static roots from gcj

Wed Mar 15 18:54:00 GMT 2006

Boehm, Hans writes:
 > > > >
 > > > > 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?
Right, I understand what you're saying. I don't think that is
possible because of the way the constant pool is created, but I'll
keep it in mind.
 > > > 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.
Fair enough. Ultimately I'd like to be able to GC shared libraries
and unmap them altogether, and clearly this argues against registering
the constant pools statically, but that's not part of the current
plan. 
Andrew.