Re: GC failure w/ THREAD_LOCAL_ALLOC ?

[Michael Smith <msmith at spinnakernet dot com>]

Boehm, Hans wrote:
>>From: Michael Smith [mailto:msmith@spinnakernet.com]
>>I've been seeing this as well and have been having difficulty tracking
>>it down.  After seeing this message, I'm starting to think this may be
>>the cause.
>>
>>I have an open FileInputStream to /dev/urandom.  An "ls -l" of
>>"/proc/<pid>/fd" shows file descriptor 51 linked to 
>>/dev/urandom.  Upon
>>a seemingly innocuous command in my app (doesn't touch 
>>anything near the
>>FileInputStream), file descriptor 51 no longer exists in 
>>/proc/<pid>/fd.
>>   Sometimes it exists as a socket instead.
>>
>>When I turned on GC_PRINT_STATS, I noticed this seemingly inncouous 
>>command involves a garbage collection.  When I started the 
>>application 
>>with an enormous initial heap size, the GC did not occur, and 
>>the fd for 
>>/dev/urandom stays around.
> 
> 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