EVALUATION

http://hg.openjdk.java.net/jdk7/hotspot-gc/hotspot/rev/c6c601a0f2d6
                                     

EVALUATION

6797870: Add -XX:+{HeapDump,PrintClassHistogram}{Before,After}FullGC

webrev: http://analemma.sfbay.sun.com/net/spot/workspaces/ysr/dump/webrev/

This is an RFE request from a financial sector customer.
See description section of the CR for their request.
Above, "Full GC" is any stop-world major gc.

When HeapDump{Before,After}FullGC is specified you get
a heap dump prior to (respectively immediately
following) a full gc. The file name for the first
such dump follows exactly the rules used for other
HeapDump* flags. Subsequent dumps append a successor
ordinal number to the name used in the first dump.

When PrintClassHistogram{Before,After}FullGC is specified
you get a class histogram of the usual kind either just
prior to or immediately following a full gc. The data
is sent to the same stream to which PrintClassHistogram
data would have gone (usually gclog file if one was
specified, and otherwise to stdout).

All flags are "manageable" and can be dynamically toggled.

Although many files have been touched, the changes are few
and the main ones limited to two files.
A main technical change in the implementation was a
suitable modification of the relevant dumping/histogram
code so that it could be called directly from the VM
thread rather than as a VM operation. This allowed us
to precisely position the snapshot for example between
a failed scavenge because of promotion failure
and the full collection that we bail out to.

While in a strict technical sense this functionality cannot
be exactly simulated using a combination of existing
tools such as jmap -dump or jmap -histo[:live], in conjunction
with suitably placed Dtrace probes, a pretty close
approximation can indeed be achieved. Of course, these
flags allow such debugging on platforms that do not support
Dtrace. Also the customer requesting the RFE was adamant that
this functionality was needed by them.

A separate RFE is extending histogram presentations to
be relativized per generation and will be available for
review in the next day or two.

The code has been tested manually under a variety of
conditions, and is being tested/evaluated by the customer.

PS: <deleted>

PPS: The RFE will be extended to G1 under a separate CR.
                                     

EVALUATION

See suggested fix section; solution under test and review.
                                     

SUGGESTED FIX

A preliminary webrev is available here:-

   http://analemma.sfbay/net/spot/workspaces/ysr/dump/webrev
                                     

EVALUATION

If the user specifies -XX:+ExplicitGCInvokesConcurrent* when using CMS, then the ensuing
GC upon a System.gc() invocation is usually a concurrent GC, rather than one of the
stop-world variety. In such cases, there are no dumps or histograms produced.
In other words, these dumps and/or histograms are produced only upon a major
stop-world gc.

Moreover, the 15% delta is being treated as advisorial in nature at the moment.
Clearly, with a heap dump it is nearly impossible to meet such a constraint
for general heaps; with a class histogram there is some chance of meeting that
constraint, but it is by no means certain that we shall be able to meet it
in a first writing without further optimization of the current histogram
collection code. However, it is true that with sufficient parallelization
of the histogram collection, it should be possible to make the histogram
collection quite efficient, but that is a separate performance RFE, not
the current feature RFE.
                                     

EVALUATION

Will, like 6808808, need CCC approval before it becomes officially
supported. Will also need to be reviewed by the serviceability and
tools groups.