Question

Following are the snapshots I took after executing perform GC from jvisualvm. Heap Stats and Permgen Stats

First image is Heap stats and 2nd one is perm gen stats. I am not able to understand when I did GC utilized heap size decreased(as expected) but the allocated size of permanent generation increased (though the utilized permgen size remained the same).What could be the possible explanation of such behavior?

JVM arguments used

-Xbootclasspath/p:../xyz.jar
-Xbootclasspath/a:../abc.jar
-Djava.endorsed.dirs=../resolver
-Djava.library.path=../framework
-Djavax.management.builder.initial=JBeanServerBuilder
-Djavax.net.ssl.trustStore=../certs
-Dorg.mortbay.log.class=JettyLogger
-Xms128m
-Xmx256m
-Xdebug
-Xnoagent
-Xrunjdwp:transport=dt_socket,server=y,suspend=y,address=2000

Note : I have changed the name(ex xyz.jar) for propriety reasons.

JVm Info:

JVM: Java HotSpot(TM) 64-Bit Server VM (23.6-b04, mixed mode)
Java: version 1.7.0_11, vendor Oracle Corporation
Java Home: /home/aniket/jdk1.7.0_11/jre
JVM Flags: <none>
Was it helpful?

Solution

  • The memory-allocation Heap/Perm/Eden/Young/S1/S2 etc spaces depends on the underlying algorithm used for GC.
  • Memory allocation to above spaces are not defined as absolute values parameters. They are defined as ratios to total heap / perm available to JVM.
  • Above two points probably point out that when Heap size changes, all memory allocations to all spaces are re-evaluated to maintain the ratio which are defined.

Below link will be really useful:

http://www.oracle.com/technetwork/java/javase/gc-tuning-6-140523.html

OTHER TIPS

since nobody offers an answer, I make my comment an answer, although it is a little vague:

I'd guess that the GC reevaluates the various sizes it has to control as part of the collection run. So it might decide that it is a little tight on the perm gen side of things an increase it.

Licensed under: CC-BY-SA with attribution
Not affiliated with StackOverflow
scroll top