GC failure w/ THREAD_LOCAL_ALLOC ?

Fri Mar 22 12:59:00 GMT 2002

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