RFR(XS) 8031065: LowMemoryTest2.sh fails: OutOfMemoryError: Metaspace

Mattias Tobiasson mattias.tobiasson at oracle.com
Thu Feb 27 04:16:10 PST 2014


Hi, thanks for the fast reviews.

I did think about stop calling loadNext() after the flag has been set. The main reason for not doing that was just because I wanted to change as little as possible. Now the test works as originally intended.
I do not mind removing the calls to loadNext(), but then we would need some timeout waiting for the callback. Currently the test "times out" with an OutOfMemory when we have allocated the remaining 20% of the space.


About line 172, you are correct. I will just remove that line. Thanks!

Mattias

----- Original Message -----
From: shanliang.jiang at oracle.com
To: daniel.fuchs at oracle.com
Cc: mattias.tobiasson at oracle.com, serviceability-dev at openjdk.java.net
Sent: Thursday, February 27, 2014 12:59:49 PM GMT +01:00 Amsterdam / Berlin / Bern / Rome / Stockholm / Vienna
Subject: Re: RFR(XS) 8031065: LowMemoryTest2.sh fails: OutOfMemoryError: Metaspace

Daniel Fuchs wrote:
> On 2/27/14 11:43 AM, Mattias Tobiasson wrote:
>> Hi,
>> Could you please review this test fix.
>>
>> The test verifies that MemoryPoolMXBean sends a notification when 
>> used memory has reached the threshold.
>> The flag thresholdExceeded marks if we have reached the memory 
>> threshold. When the flag is set, the test slows down to give time for 
>> the notification to be received.
>> The problem is that thresholdExceeded is overwritten every time in 
>> the loop. Instead it should be set if any pool has reached the 
>> threshold. This means that the test continues to allocate memory at 
>> full speed, and we may get an OutOfMemory before we get the 
>> notification.
>>
>
> Hi Mattias,
>
> I wonder whether you should also stop calling loadNext() once
> thresholdExceeded is true?
Yes I am thinking this too.

Line 172 is unnecessary, after thresholdExceeded becomes true, Line 170 
will always be skipped.

Shanliang
>
> best regards,
>
> -- daniel
>
>> bug:
>> https://bugs.openjdk.java.net/browse/JDK-8031065
>>
>> webrev:
>> http://cr.openjdk.java.net/~ykantser/8031065/webrev.00/
>>
>> Mattias
>>
>



More information about the serviceability-dev mailing list