GC failure w/ THREAD_LOCAL_ALLOC ?

Boehm, Hans hans_boehm@hp.com
Thu Mar 21 10:24:00 GMT 2002


> From: Jeff Sturm [mailto:jsturm@one-point.com]
> 
> On Wed, 20 Mar 2002, Boehm, Hans wrote:
> > GC_greatest_plausible_heap_addr is a very rough upper bound 
> on the heap.
> 
> OK, I was wondering because in my case it's awfully far from the
> heap, there's something like a 40MB hole in between the highest heap
> address and GC_greatest_plausible_heap_addr.
I think that's normal.
> 
> I can do that again.  For now I've rebuilt libgcj with conservative
> marking (no descriptors), and the failure I reported has vanished.
You should be able to get the same effect with the GC_IGNORE_GCJ_INFO
environment variable.  (See boehm-gc/doc/README.environment.)  I would still
really like to track this down, though.

> 
> When marking from a descriptor, what tests are done to ensure 
> a pointer is
> within heap boundaries?
> 
That test should be accurate.  The approximate bounds are used only to
eliminate obvious nonpointers.  It looks up the header (descriptor) for the
block (roughly page) the object resides in.  If it's not a valid object
pointer, the object isn't pushed on the mark stack.  The reasons for
segmentation faults in the marker are generally one of:

1) The collector is confused about where the roots are, e.g. because there's
an unexpected whole in the main data segment, it's confused about the
boundaries of the main data segment, or it got the wrong stack base address.
This is typically a porting problem.

2) The mark descriptor was clobbered.  This can be a consequence of a
premature object collection, due to any sort of collector bug.  Since it's
most likely to be overwritten by a pointer, this tends to make the object
look VERY large.

Hans



More information about the Java mailing list