RFC 7038914: VM could throw uncaught OOME in ReferenceHandler thread (original) (raw)

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/c1globalsx86.hpp:definepdglobal(bool, UseTLAB, true ); ./cpu/x86/vm/c2globalsx86.hpp:definepdglobal(bool, UseTLAB, true); ./cpu/zero/vm/sharkglobalszero.hpp:definepdglobal(bool, UseTLAB, true ); ./cpu/sparc/vm/c2globalssparc.hpp:definepdglobal(bool, UseTLAB, true); ./cpu/sparc/vm/c1globalssparc.hpp:definepdglobal(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 core-libs-dev mailing list