RFR 8038822: java/lang/management/MemoryMXBean/LowMemoryTest2.sh still fails with OutOfMemoryError: Metaspace

Daniel Fuchs daniel.fuchs at oracle.com
Fri Apr 4 14:19:15 UTC 2014


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.tobiasson at oracle.com
> To: daniel.fuchs at oracle.com
> Cc: serviceability-dev at 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.fuchs at oracle.com
> To: mattias.tobiasson at oracle.com, serviceability-dev at 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
>>
>



More information about the serviceability-dev mailing list