Runtime Commited Heap Resizing

New day, new version of Java... nice :)

We used to update minor Java versions mostly due to security issues. But sometimes those minor updates brings us brand new, awesome features. So was for example with 7u40 which brought us awesome Mission Control known from JRockit. (If you are interested in tracking changes across Java updates take a look at
http://www.oracle.com/technetwork/java/javase/8all-relnotes-2226344.html for Java 8 orhttp://www.java.com/en/download/faq/release_changes.xml for Java 7) 

Same situation is now with versions 7u60 and 8u20. Since now flags MinHeapFreeRatio andMaxHeapFreeRatio became manageable, which means we can change its values... in runtime :) 


You can always check which flags in JVM are manageable by invoking

java -XX:+PrintFlagsFinal -XX:+UseG1GC -version |grep manageable
intx CMSAbortablePrecleanWaitMillis  = 100  {manageable}
intx CMSWaitDuration  = 2000  {manageable}
bool HeapDumpAfterFullGC  = false  {manageable}
bool HeapDumpBeforeFullGC  = false  {manageable}
bool HeapDumpOnOutOfMemoryError  = false  {manageable}
ccstr HeapDumpPath  =  {manageable}
uintx MaxHeapFreeRatio  = 70  {manageable}
uintx MinHeapFreeRatio  = 40  {manageable}
bool PrintClassHistogram  = false  {manageable}
bool PrintClassHistogramAfterFullGC  = false  {manageable}
bool PrintClassHistogramBeforeFullGC  = false  {manageable}
bool PrintConcurrentLocks  = false  {manageable}
bool PrintGC  = false  {manageable}
bool PrintGCDateStamps  = false  {manageable}
bool PrintGCDetails  = false  {manageable}
bool PrintGCTimeStamps  = false  {manageable}
java version "1.8.0_20"
Java(TM) SE Runtime Environment (build 1.8.0_20-b26)
Java HotSpot(TM) 64-Bit Server VM (build 25.20-b23, mixed mode)

Getting back to our flags. MinHeapFreeRatio defines minimum percentage of heap free after GC to avoid expansion, while MaxHeapFreeRation (as you can expect) describes maximum percentage of heap free after GC to avoid shrinking. 

Now let's see how this heap resizing works. At first we need to find java process right for testing. I'll going to use running IntelliJ IDEA.
As you know java pids can be found by invoking jps command:

jps -l
17136 com.intellij.idea.Main

We already know our testing pid, so it's good time to find out some heap statistics. We'll use jmapcommand to do that:
As you can see I'm using G1 GC with 2GB max heap size (-Xmx2g). Heap usage is about 40%. Now we should run full gc to clean up a little bit before playing.

jcmd 17136 GC.run

Then jmap one more time and we can see 
Finally we're ready to start resezing. I will change value of MaxHeapFreeRatio flag by using jinfotool:

jinfo -flag MaxHeapFreeRatio=50 17136

After that we have to again run full gc to force resizing. And now our heap looks like that: 
As you can see heap shrank from 419 to 159 MB.

Now we can try going in other way: 

jinfo -flag MaxHeapFreeRatio=90 17136
jinfo -flag MinHeapFreeRatio=85 17136

gives jmap output 

Heap Configuration:
MinHeapFreeRatio  = 85
MaxHeapFreeRatio  = 90
Heap Usage:
G1 Heap:
regions  = 2048
capacity = 465567744 (444.0MB)
used  = 69816504 (66.58220672607422MB)
free  = 395751240 (377.4177932739258MB)
14.995992505872572% used

Resizing worked one more time and heap capacity has increased from 159MB to 444MB. We described that minimum 85% of our heap capacity should be free, and that pointed JVM to resize the heap to gain at most 15% usage. Now we're waiting for runtime XMX changing ;)