EVALUATION

http://hg.openjdk.java.net/lambda/lambda/hotspot/rev/23c0eb012d6f
                                     

EVALUATION

http://hg.openjdk.java.net/hsx/hotspot-comp/hotspot/rev/23c0eb012d6f
                                     

EVALUATION

http://hg.openjdk.java.net/hsx/hotspot-gc/hotspot/rev/23c0eb012d6f
                                     

WORK AROUND

1.  Add the command line option
    -XX:GCHeapFreeLimit=<N>
Here <N> is a percentage from 0-100 that defines the maximum percentage of free
space in the heap allowed when throwing an OutOfMemoryError because the JVM is
spending "too much" time in GC.  Recommend value of <N> to workaround this bug
is in the range 10-40; the exact value is dependent on the relative sizes of the
young and old generation.  Note that this simply causes the JVM to throw an
OutOfMemoryError earlier than it currently does because the GC overhead is too high;
it doesn't change the way the collector behaves.

2.  Reduce the value of PromotedPadding to 1 or 0 (the default value is 3).  Use the
command line option
    -XX:PromotedPadding=1
PromotedPadding is used when deciding whether to perform a Young GC or a Full GC.
A smaller value may allow Young GCs to be attempted instead of Full GCs as the
heap becomes more full.

Both the above are only partial workarounds; they will not solve the problem for
all applications.
                                     

EVALUATION

I think this is at least partially due to the way parallel compaction deals with
the young gen.  When copying from a young gen space (e.g., eden or from) to the
old gen, *all* live objects in the space must fit into the old gen; otherwise,
none of them will be copied.  This is because par compaction operates on
'regions' of the heap and copying only part of a space would require extra
bookkeeping (or some good luck).

A scavenge, if it were done, would be able to promote some things into the
old gen.  Even though scavenge before full gc is enabled, the scavenge code
bails out because the estimated amount of bytes promoted is > the amount of
free space in the old gen (in PSScavenge::should_attempt_scavenge()).

I expected the gc overhead limit to kick in, since we are spending nearly all
our time in GC and not collecting anything.  We should get an OOME because we
are spending too much time in GC.  Update after a conversation with the
implemtor of the overhead limit:  the overhead limit is not triggered because
there is too much free space in the old generation (more than 2%).

Could modify the policy so that when the estimated bytes to promote is > the
free space in the old gen, a scavenge is skipped only if the last scavenge
was not skipped for the same reason.  In other (simpler) words, don't skip
consecutive scavenges.