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: [email protected] To: [email protected], [email protected] 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 >
