G1GC, Java8u40ea, Metaspace questions

[Wolfgang Pedot]

Hi

Am 18.02.2015 05:12, schrieb Yu Zhang:
> Hi,
>
> After discussing with the developers, here is the explanation:
> >shows a slow but continuous increase of the "commited" value for 
> Metaspace even though "used" after a collect is quite stable and 
> "commited" is shrunk after every collect.
>
> This might be due to fragmentation in metadata space.  Even though the 
> total used is stable, the memory is fragmented so it has to allocate 
> more.  If you have Flight Recorder(a commercial feature), you can see 
> this information in JFR.

Unfortunately I do not have JFR available, however I did notice that the 
number of classes that fit into Metaspace before the collect also kept 
increasing so it cant all be fragmentation.

> >I have found out that I need to set Min and MaxMetaspaceFreeRatio 
> really really low (like <=10%) to keep the high-water-mark in check 
> and I dont quite see why in the numbers.
>
> This might be related to how the high water mark is calculated. There 
> are some ways to improve this but not implemented yet.

The more I test the more I come to the conclusion that there is 
something strange about that calculation (or my understanding of it). I 
am currently running a very long test on 64bit linux (>9million classes 
loaded so far) and there is a definite upwards trend of both the HWM and 
used-after-GC. Class unloading does not seem to be as successful when a 
concurrent cycle is triggered by Metaspace threshold compared to a 
Full-GC and that gap is growing over time. I guess thats because the 
heap of the test-JVM is rather large and empty and since G1 is allowed 
to waste 5% if it that means some classloaders stay alive longer 
although that should stabilize at some point. Increasing the usage in 
oldGen from ~0.5GB to ~1GB made class unloading "better" for one collect.

The high-point of Metaspace usage slowly increased from ~400MB to ~600MB 
during the first part of the test and used-after-GC started at 200MB and 
crept up to around 400MB. I decided to throw in a manual FullGC during 
the test to see what happens and that brought the usage down to ~110MB 
as it should be so there is no real class-leak. Since 
MaxMetaspaceFreeRatio is configured to 30% (Min is 10%) I would have 
expected the HWM to go down after that collect but appearantly it did 
not, it stayed at ~600MB for the next collect and then went up another 
~50MB.
I dont really see the HWM-value so when I write "HWM" I am referring to 
the highest point of Metaspace-usage before a collect is initiated.

I have attached a screenshot of jconsole showing the part with the 
FullGC (~9:40), I reconnected to the JVM at ~8:55 so it does not cover 
the whole uptime.

Is this expected or explainable behaviour? The way I see it the high 
points of that curve may keep on climbing until they hit the limit and 
after that its FullGCs all the time.

regards
Wolfgang

-------------- next part --------------
A non-text attachment was scrubbed...
Name: jconsole_8u40_2048_30_10_fullgc.png
Type: image/png
Size: 102718 bytes
Desc: not available
URL: <http://mail.openjdk.java.net/pipermail/hotspot-gc-use/attachments/20150219/a80932df/jconsole_8u40_2048_30_10_fullgc-0001.png>