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
