JDK-8215771 : The jfr tool should pretty print reference chains
  • Type: Enhancement
  • Component: hotspot
  • Sub-Component: jfr
  • Affected Version: 11,12,13
  • Priority: P3
  • Status: Resolved
  • Resolution: Fixed
  • Submitted: 2018-12-21
  • Updated: 2020-04-27
  • Resolved: 2019-01-04
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 11 JDK 13 Other
11.0.6Fixed 13 b03Fixed openjdk8u262Fixed
Related Reports
Relates :  
Description
The JDK_HOME/bin/jfr tool can be used to print Old Object Sample events, useful for solving memory leaks. If the recording was dumped with path-to-gc-roots=true, the event will also contain reference chains from the object samples to the gc roots. This is useful for finding unexpected and unintended references, for example a HashMap object holding on to an object it shouldn't.

The chain can be extracted today like this:

$ java -XX:StartFlightRecording ...
...
$ jfr <pid> JFR.dump path-to-gc-roots=true filename=dump.jfr 
$ jfr print --events OldObjectSample dump.jfr 

But the printout is very verbose and it expands horizontally, a few columns for every new reference in  the chain, making it very hard to parse when it wraps. The proposed solution is to add logic to the jfr tool pretty printer, similar to what today exists for stack traces, so it is printed in a compact and human-readable way. 

The chain should be printed vertically, perhaps with the field (or position in the array) to the left and then the type of object it is and then additional information if it exists, such as size if it is a java.util.Collection, 

jdk.OldObjectSample {
  startTime = 09:50:46.350
  allocationTime = 09:50:39.201
  lastKnownHeapUsage = 1200.3 MB
  object = int[10000]  (Sample) { 
      data sun.awt.image.IntegerInterleavedRatser
      biRatser sun.awt.image.ImageRepresentation
      imagerep sun.awt.image.ToolkitImage
      reference sun.awt.SoftCache$ValueCell
      value java.util.HashMap$Node
      next java.util.HashMap$Node
      [2] java.util.HashMap$Node[64]
      table java.util.HashMap (Size: 32)
      hash sun.awt.SoftCache
      urlImgCache java.lang.Class (GC Root)
  }
  eventThread = "AWT-EventQueue-0" (javaThreadId = 30)
}

This is typically sufficient information to solve the memory leak, if you SSH into a machine, without transferring files or using other tools.
Comments
Replacing jdk8u-fix-request with link to JDK-8239140
17-02-2020

RFC: https://mail.openjdk.java.net/pipermail/jdk8u-dev/2020-January/011063.html
30-01-2020

Fix Request (11u): This small patch improves the output of reference chains and makes for a clean backport of JDK-8223697. The patch applied cleanly. The tier one and jfr tests passed on my machine.
24-10-2019