Analysis on JDK-8022321 java/lang/ref/ fails intermittently

Peter Levart peter.levart at
Sat Jan 11 14:15:29 UTC 2014

On 01/10/2014 10:51 PM, srikalyan chandrashekar wrote:
> Hi Peter the version you provided ran indefinitely(i put a 10 minute 
> timeout) and the program got interrupted(no error),

Did you run it with or without fastedbug & -XX:+TraceExceptions ? If 
with, it might be that fastdebug and/or -XX:+TraceExceptions changes the 
execution a bit so that we can no longer reproduce the wrong behaviour.

> even if there were to be an error you cannot print the "string" of 
> thread to console(these have been attempted earlier). has been attempted to print toString in uncaught exception 
handler. At that time, the heap is still full. I'm printing it after the 
GC has cleared the heap. You can try that it works by commenting out the 
"try {" and corresponding "} catch (OOME x) {}" exception handler...

> - The test's running on interpreter mode, what i am watching for is 
> one error with trace. Without fastdebug build and -XX:+TraceExceptions 
> i am able to reproduce failure atleast 5 failures out of 1000 runs but 
> with fastdebug+Trace no luck yet(already past few 1000 runs).

It might be interesting to try with fastebug build but without the 
-XX:+TraceExceptions option to see what has an effect on it. It might 
also be interesting to try the modified ReferenceHandler (the one with 
private runImpl() method called from run()) and with normal 
non-fastdebug JDK. This info might be useful when one starts to inspect 
the exception handling code in interpreter...

Regards, Peter

> ---
> Thanks
> kalyan
> On 01/10/2014 02:57 AM, Peter Levart wrote:
>> On 01/10/2014 09:31 AM, Peter Levart wrote:
>>> Since we suspect there's something wrong with exception handling in 
>>> interpreter, I devised a hypothetical reproducer that tries to 
>>> simulate ReferenceHandler in many aspects, but doesn't require to be 
>>> a ReferenceHandler:
>>> This is designed to run indefinitely and only terminate if/when 
>>> thread dies. Could you run this program in the environment that 
>>> causes the OOMEInReferenceHandler test to fail and see if it 
>>> terminates?
>> I forgot to mention that in order for this long-running program to 
>> exhibit interpreter behaviour, it should be run with -Xint option. So 
>> I suggest:
>> -Xmx24M -XX:-UseTLAB -Xint
>> Regards, Peter

More information about the core-libs-dev mailing list