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.