[prev in list] [next in list] [prev in thread] [next in thread] 

List:       openjdk-serviceability-dev
Subject:    Re: RFR 8038822: java/lang/management/MemoryMXBean/LowMemoryTest2.sh still fails with OutOfMemoryErr
From:       Daniel Fuchs <daniel.fuchs () oracle ! com>
Date:       2014-04-04 14:19:15
Message-ID: 533EBF63.6040402 () oracle ! com
[Download RAW message or body]

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@oracle.com
> To: daniel.fuchs@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.fuchs@oracle.com
> To: mattias.tobiasson@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
> > 
> 


[prev in list] [next in list] [prev in thread] [next in thread]