Logo Questions Linux Laravel Mysql Ubuntu Git Menu
 

How can I make the old region resize adaptively in Java GC?

For tuning the Java 6 (1.6.0_23) GC, I use -XX:+UseParallelOldGC along with

-XX:+PrintTenuringDistribution
-XX:+UseAdaptiveSizePolicy
-XX:+UseAdaptiveGCBoundary

My goal is to let the GC compute an optimal ratio between old and new regions. However, visualgc (jvmstat 3.0) shows that while the ratio between the eden and the survivors is modified according to my workload, the old region remains (desperately) at its initial size, fixed by the newRatio (2 in my case).

What is wrong with my settings or expectations?

On my screen, after 19 collections visualgc shows the old Gen constantly under 500m while the reserved and committed sizes of the old Gen are equal to 624m. I have set NewSize to 30m and MaxNewSize to 300m, but this does not change anything: NewRatio seems untangible... PrintAdaptiveSizePolicy only speaks about survivor.

The point is that the "reserved space" menu of visualgc does not show anything for the Old Gen space... I have tryed also in using -XX:+UseAdaptiveGCBoundary without any change.

Here are some logs -XX:+PrintTenuringDistribution -XX:+PrintGCDetails

There is a full gc, and the final print of the heap... It seems that the tenured distribution is garbled, too...

Desired survivor size 119275520 bytes, new threshold 1 (max 15)
[PSYoungGen: 182096K->66576K(233024K)] 681978K->631994K(932096K), 0.2582390 secs] [Times: user=0.29 sys=0.00, real=0.26 secs]
116.431: [GC
Desired survivor size 119275520 bytes, new threshold 1 (max 15)
[PSYoungGen: 183120K->39952K(233024K)] 748538K->670910K(932096K), 0.1578620 secs] [Times: user=0.29 sys=0.00, real=0.16 secs]
116.589: [Full GC [PSYoungGen: 39952K->0K(233024K)] [ParOldGen: 630958K->310429K(699072K)] 670910K->310429K(932096K) [PSPermGen: 21973K->21973K(30592K)], 1.3326720 secs] [Times: user=1.79 sys=0.01, real=1.33 secs]
118.050: [GC
Desired survivor size 119275520 bytes, new threshold 1 (max 15)
[PSYoungGen: 116544K->18448K(233024K)] 426973K->328877K(932096K), 0.0745320 secs] [Times: user=0.14 sys=0.00, real=0.08 secs]
118.234: [GC
Desired survivor size 119275520 bytes, new threshold 1 (max 15)
[PSYoungGen: 134992K->24592K(233024K)] 445421K->351409K(932096K), 0.1290960 secs] [Times: user=0.14 sys=0.00, real=0.13 secs]
118.526: [GC
Desired survivor size 114884608 bytes, new threshold 1 (max 15)
[PSYoungGen: 141136K->36880K(237312K)] 467953K->380085K(936384K), 0.1187320 secs] [Times: user=0.21 sys=0.00, real=0.12 secs]
118.759: [GC
Desired survivor size 108593152 bytes, new threshold 1 (max 15)
[PSYoungGen: 142446K->40976K(233024K)] 485652K->416957K(932096K), 0.1153230 secs] [Times: user=0.23 sys=0.00, real=0.12 secs]
Heap
PSYoungGen total 233024K, used 97957K (0xb3a40000, 0x9e4f0000, 0x9e4f0000]
eden space 120832K, 47% used [0x9e4f0000,0xa1c95668,0xa5af0000)
from space 112192K, 36% used [0xa5af0000,0xa82f4020,0xac880000)
to space 106048K, 0% used [0xad2b0000,0xad2b0000,0xb3a40000)
ParOldGen total 699072K, used 375981K [0x73a40000, 0x9e4f0000, 0x9e4f0000)
object space 699072K, 53% used [0x73a40000,0x8a96b730,0x9e4f0000)
PSPermGen total 30592K, used 21981K [0x6fa40000, 0x71820000, 0x73a40000)
object space 30592K, 71% used [0x6fa40000,0x70fb7668,0x71820000)
like image 503
loginor Avatar asked Mar 28 '11 13:03

loginor


1 Answers

How can I make the old region resize adaptively in Java GC?

I don't think that it is possible. The GC has a limited set of "tuning knobs", and I can't see one that would do this for you. My feeling is that you are "over thinking" the problem.

Reference:

  • A Collection of JVM Options by Joseph D. Mocker (Sun Microsystems, Inc.)

If this answer is not good enough, your options are rather limited:

  • If you went through the appropriate channels and were prepared to fork out some money, you could probably get some help from an Oracle tuning expert.

  • If you had the time and patience, you could try to get your head around the GC source code in the OpenJDK code-base.

like image 194
Stephen C Avatar answered Oct 11 '22 20:10

Stephen C