CODEWITHSUNDEEP
jvmresizeheap-memory
pf_miles
pf_miles

Reputation: 927

jvm heap resize when -Xmx and -Xms are the same though

I have a stand-lone java app, which jvm params are:

-Xmx2g -Xms2g -Xmn1g -XX:PermSize=96m -XX:+DisableExplicitGC 
-XX:+UseFastAccessorMethods  -XX:+UseParallelGC -XX:+UseParallelOldGC 
-XX:MaxTenuringThreshold=63 -Djava.awt.headless=true -Djava.net.preferIPv4Stack=true

as we can see, -Xmx and -Xms are all 2g, but I found the heap size always resize a bit: the red line represents the total heap size, the blue one represents used

the red line represents the total heap size, the blue one represents used I think the red line should be straight, but it wasn't. But in another web app, which jvm params are: 

-Xmx2g -Xms2g -Xmn512m -XX:PermSize=196m -Xss256k -XX:+DisableExplicitGC 
-XX:+UseConcMarkSweepGC -XX:+CMSParallelRemarkEnabled 
-XX:+UseCMSCompactAtFullCollection -XX:LargePageSizeInBytes=128m 
-XX:+UseFastAccessorMethods -XX:+UseCMSInitiatingOccupancyOnly 
-XX:CMSInitiatingOccupancyFraction=70 -XX:-ReduceInitialCardMarks 
-Djava.awt.headless=true -Djava.net.preferIPv4Stack=true

its visual heap usage chart is:

heap not resize when cms gc

The total heap size is exactly as much as 2g and the red line is horizontal stable, that's what I think it should be.

The main difference of the two apps are the GC strategy used, one is parallel GC and the other is CMS. Does the GC strategy has any effect on the resizing of the heap space? Or the -Xmn param has some effects on heap resizing that I didn't know?

Upvotes: 0

Views: 1570

Answers (1)

Greg Bowyer
Greg Bowyer

Reputation: 1684

Parallel GC does some tricks through something known as GC ergonomics, which attempt to resize the internal heap sizes (OLD, new, perm etc) at runtime to help meat throughput or latency goals.

Its possible that the monitoring tool is not expecting to see parts of the heap resize and is reporting these resizes directly rather than smoothing it out.

Upvotes: 1

Related Questions