JDK-6797870 : Add -XX:+{HeapDump,PrintClassHistogram}{Before,After}FullGC
  • Type: Enhancement
  • Component: hotspot
  • Sub-Component: gc
  • Affected Version: 6u7,7
  • Priority: P3
  • Status: Closed
  • Resolution: Fixed
  • OS: generic,solaris_10
  • CPU: generic,x86
  • Submitted: 2009-01-26
  • Updated: 2017-05-16
  • Resolved: 2011-03-07
The Version table provides details related to the release that this issue/RFE will be addressed.

Unresolved : Release in which this issue/RFE will be addressed.
Resolved: Release in which this issue/RFE has been resolved.
Fixed : Release in which this issue/RFE has been fixed. The release containing this fix may be available for download as an Early Access Release or a General Availability Release.

To download the current JDK release, click here.
JDK 6 JDK 7 Other
6u18Fixed 7Fixed hs15Fixed
Related Reports
Relates :  
JDK-6818264 - Heap dumper unexpectedly adds .hprof suffix
Relates :  
JDK-6808808 - Per-generation class histograms with PrintClassHistogram*
Relates :  
JDK-6454676 - Need -XX:+HeapDumpOnCtrlBreak to trigger heap dump on ctrl-break or ctrl-\
Relates :  
JDK-6810861 - G1: support -XX:+{PrintClassHistogram,HeapDump}{Before,After}FullGC
Description
Add a -XX:+HeapDumpBeforeFullGC that produces a heap dump when a full gc becomes necessary,
whether because of a promotion failure, concurrent mode failure, explicit request or other
reason.  The heap dump can then be analyzed to discover which objects/classes dominate the
set of live objects and thus provide clues to application developers about which objects
and classes to focus on so as to decrease or eliminate the chances of a full gc.  The
heap dump should not increase full gc time by more than 15%.  This is a somewhat vague
number since full gc time depends on things like the percentage of live data in the heap,
but it gives a sense of the tolerable overhead.
Modified synopsis from the original:-

  "Add -XX:+HeapDumpBeforeFullGC"

to:-

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

based on discussions (also with requesting customer).
Comments
EVALUATION http://hg.openjdk.java.net/jdk7/hotspot-gc/hotspot/rev/c6c601a0f2d6
03-03-2009
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.
27-02-2009
EVALUATION Will, like 6808808, need CCC approval before it becomes officially supported. Will also need to be reviewed by the serviceability and tools groups.
23-02-2009
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.
23-02-2009
EVALUATION See suggested fix section; solution under test and review.
23-02-2009
SUGGESTED FIX A preliminary webrev is available here:- http://analemma.sfbay/net/spot/workspaces/ysr/dump/webrev
23-02-2009