RFC 7038914: VM could throw uncaught OOME in ReferenceHandler thread
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
> 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,
> ./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,
> ./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 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.
>> Regards, Peter
More information about the hotspot-gc-dev