RFC 7038914: VM could throw uncaught OOME in ReferenceHandler thread

[David Holmes]

On 9/05/2013 8:40 PM, Peter Levart wrote:
> 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.

I can't answer that - GC folk?

David
-----

> 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
>>>
>