RFC 7038914: VM could throw uncaught OOME in ReferenceHandler thread

Peter Levart peter.levart at gmail.com
Thu May 9 10:40:50 UTC 2013

On 05/09/2013 12:08 PM, David Holmes wrote:
> On 9/05/2013 7:18 PM, Peter Levart wrote:
>> On 05/09/2013 07:53 AM, David Holmes wrote:
>>> Have you instrumented the code to verify that the test actually
>>> triggers an OOME?
>> Without the patch, the test always throws OOME in lock.wait() and kills
>> the thread. At least in all executions I tried (100s) it did the same.
> How many different platforms could you try?
>> The test might pass without a patch only perhaps when TLABs are used.
>> The default is: -XX:-UseTLAB right? Perhaps it should be specified
>> explicitly...
> UseTLAB is true by default on most platforms:
> ./cpu/x86/vm/c1_globals_x86.hpp:define_pd_global(bool, UseTLAB, 
>              true );
> ./cpu/x86/vm/c2_globals_x86.hpp:define_pd_global(bool, UseTLAB, 
>              true);
> ./cpu/zero/vm/shark_globals_zero.hpp:define_pd_global(bool, UseTLAB, 
>                      true );
> ./cpu/sparc/vm/c2_globals_sparc.hpp:define_pd_global(bool, UseTLAB, 
>                  true);
> ./cpu/sparc/vm/c1_globals_sparc.hpp:define_pd_global(bool, UseTLAB, 
>                  true );

Hm, interesting. How do you explain that the allocation of a simple 
InterruptedException fails in Reference Handler thread after the 'main' 
thread has burnt all the heap including it's own TLAB? Is it just by 
chance that there was not enough space in Reference Handler's TLAB to 
allocate the exception? Is TLAB allocated lazily when the thread does 
it's 1st allocation? There're no allocations in the ReferenceHandler's 
run() method (excluding Cleaners), so the InterruptedException might be 
it's 1st allocation. To be more robust, we should specify -XX:-UseTLAB 
to run the test.

Regards, Peter

> I don't expect the test to be absolutely foolproof on every platform 
> but it would be good to know it actually catches the bug on our test 
> systems :) Something Thomas should be able to test I hope.
> Thanks,
> David
>> Regards, Peter

More information about the hotspot-gc-dev mailing list