GC failure w/ THREAD_LOCAL_ALLOC ?

Boehm, Hans hans_boehm@hp.com
Fri Mar 22 22:13:00 GMT 2002


Can you put a breakpoint in close() to verify that the descriptor is being
closed by a finalizer?

If you can repeat this, and the GC is responsible, and you can figure out
which object is getting collected, a good thing to do is to put a breakpoint
in GC_finish_collection() during the offending GC, and then invoke
GC_is_marked() on all objects in the reference chain from the debugger, with
the process still stopped in GC_finish_collection.  If you find a marked
object pointing to an unmarked one, it would be good to know the results of 

print *GC_find_header(<last marked>)

If it's a gcj object, so would the mark descriptor.

I'm also suspicious that this is a completely separate problem, possibly
outside the GC.

Hans

-----Original Message-----
From: Michael Smith

> 
> Do you know how the FileInputStream is referenced?  Is it only
referenced
> from the stack?  Does the reference chain go through large objects,
> particularly through objects which have pointers at displacements >
100 or
> so?  

Referenced as a member variable of an instantiated java object, so its 
referenced from the heap.  That instantiated java object is held by a 
static class variable.  Neither of those two objects are particularly 
large, with no more than 6 member variables.

>>Hans, do you have enough information about the mark descriptor
>>clobbering to recommend a workaround even if you don't know 
>>exactly what
>>the problem is?  For example, are you reasonably confident 
>>that building
>>with THREAD_LOCAL_ALLOC or USE_PTHREAD_SPECIFIC or something 
>>else will 
>>eliminate the problem (and not just "hide" it like GC_IGNORE_GCJ_INFO 
>>seems to do)?
>>
> 
> Assuming it appears to work, I have the greatest confidence in
> GC_IGNORE_GCJ_INFO.  This sidesteps a lot of subtle issues in the
collector,
> at the expense of possibly retaining extraneous memory.  But without
fully
> understanding the problem, it's hard to say for sure.  Turning off
> THREAD_LOCAL_ALLOC would be my next choice.  My current assumption is
that
> Jeff was seeing a different problem.

I've been running with GC_IGNORE_GCJ_INFO for a month now.  I haven't 
seen the GC deadlock (same problem Bryce described) since I started 
using this option.  I *am* seeing the my file descriptor disappear using

this option.  So, maybe this file descriptor thing really is a separate 
problem.

> I'm currently in the middle of tracking down the (n+1)st Itanium stack
> unwinding issue.  I'll get back to trying to reproduce this after
that.  If
> someone else has a similar failure report, especially with older glibc
> versions, that would be helpful.

Any pointers on what other information may be useful to you?  If I can 
do some tests now, then maybe you can have an easier time once you can 
pick this problem up.  Right now, I know of no workaround for this file 
descriptor problem, so the sooner it gets resolved, the better.

regards,
michael



More information about the Java mailing list