RE: GC failure w/ THREAD_LOCAL_ALLOC ?

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

FWIW -

I believe I have an explanation of the original problem, though I need to
think a little more about the best way to fix it, and I can't completely
confirm this without the fix (and perhaps not even then). 

The problem should be limited to gcj objects.  Turning off gcj type
information (GC_IGNORE_GCJ_INFO environment variable) should be an adequate
work-around for now.  My guess is that this can occur with or without
thread-local allocation, though there are probably reasons to expect that
thread-local allocation increases the occurrence probability.

Details:

  The problem is that at the end of a collection cycle, in GC_start_reclaim,
free lists remaining from the last GC cycle are just dropped, since they
will be rebuilt.  My guess is:

1) A short free list of gcj objects is dropped.  The page containing it is
scheduled to be reclaimed (swept) in the next cycle.

2) Objects of that size end up being in low demand or the GC is invoked
explicitly, and thus the page is never actually swept, and the free list
remains.

3) The next mark phase sees a bogus pointer to part of the free list.  Since
the referenced object appears to have a 0 mark descriptor, the rest of the
free list is not marked.

4) The rest of the free list is reallocated.  The one object that was
accidentally marked remmains as it was.

5) The next mark cycle sees an object (the accidentally marked one) with a
vtable/free list pointer that points to an in-use object.  It's second word
is nonzero and causes the collector crash when it is misinterpreted as a
mark descriptor.

I clearly need to be more careful about just dropping freelists with gcj
objects.  But this shouldn't be hard to fix.

Hans

> -----Original Message-----
> From: Michael Smith [mailto:msmith@spinnakernet.com]
> Sent: Thursday, March 28, 2002 6:52 AM
> To: tromey@redhat.com; Boehm, Hans
> Cc: 'Michael Smith'; 'Jeff Sturm '; ''Bryce McKinlay ' '
> Subject: RE: GC failure w/ THREAD_LOCAL_ALLOC ?
> 
> 
>  > And here I thought that bug was mostly theoretical.
>  > It's always nice to find out when the details matter.  Thanks.
>  >
>  > Tom
> 
> No, thank *you*.  Saved me some work trying to fix it myself.  :)
> 
> Do you want the test case I wrote that showed the Process stuff 
> breaking?  It wasn't that hard to write one (Once I figured 
> out how/why 
> it was happening):
> 
> 1. Exec process with executable name that doesn't exist.
> 2. Open a file for reading.
> 3. Force garbage collection.
> 4. Read from file. --> IOException: Bad File Descriptor
> 
> regards,
> michael
>