Large variation in size of Eden and Survivor with every garbage
collection. It appears that the VM is unable to adapt to the constant
load on the system. If we try to turn off the adaptive sizing using -
XX:-UseAdaptiveSizePolicy then we get bizarre behavior in which the
Survivor size remains small - resulting in large overflows of objects
to the Old space. -XX:SurvivorRatio=2, or set to any value, has no
impact on the space actually allocated for Eden or Survivor. This
prevents any type of tuning and leads to poor performance,
particularly with very large heaps.
/opt/java1.4/bin/java -Xverbosegc -Xmx11m -Xms11m -Xmn3m -
XX:SurvivorRatio=2 -XX:+UseParallelGC xxx
<GCH: argXms=11264 >
<GCH: argXmx=11264 >
<GCH: optNewSize=3072 >
<GCH: optMaxNewSize=3072 >
<GCH: optOldSize=4096 >
<GCH: optNewRatio=2 >
<GCH: optSurvivorRatio=2 >
<GCH: optUseParNewGC=0 >
<GCH: optUseParallelGC=1 >
<GCH: optUseAdaptiveSizePolicy=1 >
<GCH: reservnew=3072 >
<GCH: initnew=3072 >
<GCH: reservold=9216 >
<GCH: initold=8192 >
<GCH: reservperm=65536 >
<GCH: initperm=16384 >
<GCH: survsize=384 > -- this is what we get - much too small!!!
<GCH: edensize=2304 >
Problems:-
1. When I do use UseParallelGC and turn off the adaptive size policy,
the default calculation makes the Survivor space very small.
2. When I try to increase the size of the Survivor space using
SurvivorRatio, I cannot get it to work.
3. There are wild vacillations in the sizes of Eden and Survivor -
there seems to be little dampening of this wild behavior.
4. After the Old space fills up, a Full GC occurs - that's okay. But
then a couple of minutes later, for no apparent reason, another Full
GC occurs - and this pattern repeats.
The net effect is very poor performance.
collection. It appears that the VM is unable to adapt to the constant
load on the system. If we try to turn off the adaptive sizing using -
XX:-UseAdaptiveSizePolicy then we get bizarre behavior in which the
Survivor size remains small - resulting in large overflows of objects
to the Old space. -XX:SurvivorRatio=2, or set to any value, has no
impact on the space actually allocated for Eden or Survivor. This
prevents any type of tuning and leads to poor performance,
particularly with very large heaps.
/opt/java1.4/bin/java -Xverbosegc -Xmx11m -Xms11m -Xmn3m -
XX:SurvivorRatio=2 -XX:+UseParallelGC xxx
<GCH: argXms=11264 >
<GCH: argXmx=11264 >
<GCH: optNewSize=3072 >
<GCH: optMaxNewSize=3072 >
<GCH: optOldSize=4096 >
<GCH: optNewRatio=2 >
<GCH: optSurvivorRatio=2 >
<GCH: optUseParNewGC=0 >
<GCH: optUseParallelGC=1 >
<GCH: optUseAdaptiveSizePolicy=1 >
<GCH: reservnew=3072 >
<GCH: initnew=3072 >
<GCH: reservold=9216 >
<GCH: initold=8192 >
<GCH: reservperm=65536 >
<GCH: initperm=16384 >
<GCH: survsize=384 > -- this is what we get - much too small!!!
<GCH: edensize=2304 >
Problems:-
1. When I do use UseParallelGC and turn off the adaptive size policy,
the default calculation makes the Survivor space very small.
2. When I try to increase the size of the Survivor space using
SurvivorRatio, I cannot get it to work.
3. There are wild vacillations in the sizes of Eden and Survivor -
there seems to be little dampening of this wild behavior.
4. After the Old space fills up, a Full GC occurs - that's okay. But
then a couple of minutes later, for no apparent reason, another Full
GC occurs - and this pattern repeats.
The net effect is very poor performance.
- relates to
-
JDK-6362902 Use uniform names for GC flags/parameters/names/verbose-logs across all collectors whenever possible
-
- Resolved
-
-
JDK-6314461 from-space does not relinquish space at full collections.
-
- Closed
-