On 4/4/14 2:20 PM, Mattias Tobiasson wrote:
Hi Daniel,
Could you please sponsor the attached patch?
Webrev: http://cr.openjdk.java.net/~ykantser/8038822/webrev.01
The only change is that I have made BoundlessLoaderThread.pool final.
No Problem Mattias, I'll do it!
-- daniel
Mattias
----- Original Message -----
From: mattias.tobias...@oracle.com
To: daniel.fu...@oracle.com
Cc: serviceability-dev@openjdk.java.net
Sent: Thursday, April 3, 2014 4:41:46 PM GMT +01:00 Amsterdam / Berlin / Bern /
Rome / Stockholm / Vienna
Subject: Re: RFR 8038822: java/lang/management/MemoryMXBean/LowMemoryTest2.sh
still fails with OutOfMemoryError: Metaspace
Thanks for the feedback.
I first tried to call gc() unconditionally, but then the duration of the test
increased from 2 to 25 seconds. I was surprised it made such a difference.
I will make BoundlessLoaderThread.pool final.
Mattias
----- Original Message -----
From: daniel.fu...@oracle.com
To: mattias.tobias...@oracle.com, serviceability-dev@openjdk.java.net
Sent: Thursday, April 3, 2014 4:03:45 PM GMT +01:00 Amsterdam / Berlin / Bern /
Rome / Stockholm / Vienna
Subject: Re: RFR 8038822: java/lang/management/MemoryMXBean/LowMemoryTest2.sh
still fails with OutOfMemoryError: Metaspace
Hi Mattias,
This looks good.
Maybe you could afford to call gc() unconditionally
instead of only when isAnyUsageAboveThreshold(pools) returns
true.
This may be taken into consideration if this test fails again ;-(
Small nit: BoundlessLoaderThread.pool could be declared final.
best regards,
-- daniel
On 4/3/14 1:58 PM, Mattias Tobiasson wrote:
Hi,
This test sometimes fails with OutOfMemory. It fails rarely, I have not been
able to reproduce it.
The test keeps loading new classes until MemoryMXBean.getUsageThresholdCount()
> 0.
UsageThresholdCount is only updated during a GC. My guess is that the test
loads classes
too fast so we run out of memory before the flag is set.
This fix will force a GC when used memory is above the threshold.
That should update the UsageThresholdCount immediately.
I have also added more logging if the test fails again.
changes:
1. Force a GC if memory usage is above threshold.
2. Split the big check pools loop into sub functions.
3. "pools" list only contains the relevant pools,
instead of keeping all pools and filter them each loop.
webrev: http://cr.openjdk.java.net/~ykantser/8038822/webrev.00
bug: https://bugs.openjdk.java.net/browse/JDK-8038822
Mattias
