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