GC failure w/ THREAD_LOCAL_ALLOC ?

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


> 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? 
>>> 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'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.
Hans


More information about the Java mailing list

AltStyle によって変換されたページ (->オリジナル) /