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

[Mattias Tobiasson]

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
>