Thanks Erik. PromoteObject events do cover my exact target objects, but they are the equivalent of GC.class_histogram compared to GC.heap_dump - I can't see the relationships between objects (nor the object contents, but I care less about that). The class histogram from my real examples shows something like `byte[], Date, Double, Object[]` as the top contributors. It's hard to figure out where these are from. There might be an angle similar to the existing JFR path-to-gc-roots feature, but I'm guessing that's more complex than my idea.
Oli ________________________________________ From: Erik Gahlin <[email protected]> Sent: 13 November 2026 15:11 To: Gillespie, Oli; [email protected] Subject: RE: [EXTERNAL] [External] : Proposal: young-only heap dumps CAUTION: This email originated from outside of the organization. Do not click links or open attachments unless you can confirm the sender and know the content is safe. Not sure if this fulfills your use case, but have you looked at the JFR events PromoteObjectInNewPLAB and PromoteObjectOutsidePLAB? $ java -XX:StartFlightRecording: \ jdk.PromoteObjectInNewPLAB#enabled=true, \ jdk.PromoteObjectOutsidePLAB#enabled=true ... For more information: $ jfr metadata --events PromoteObjectInNewPLAB,PromoteObjectOutsidePLAB Erik ________________________________________ From: Gillespie, Oli <[email protected]> Sent: Friday, November 13, 2026 3:01 PM To: [email protected] Subject: [External] : Proposal: young-only heap dumps Hi, I'd like to propose offering live-young-only heap dumps to allow optimising young gc pause times. This is a heap dump which only includes objects that are live in the young generation - jcmd GC.heap_dump -generation=young. Main use case is to allow users to reduce young GC pause times which are dominated by live-object evacuation. Young GC evacuates exactly the set of objects that are live in the young generation, so this dump represents the evacuation set. Users can then load it in existing hprof tools and understand what dominates their evacuation set. This is often very different from allocation profiling, or a full heap dump, and I know of no other way to get this information. Allocation profiles or '-all' heap dumps are dominated by ephemeral data, the bulk of which is already dead and not evacuated during young GC. A live heap dump is often dominated by old objects, also not evacuated in young GC. Live-young pinpoints the relevant data. Implementation is small and simple, an extra flag in the diagnostic command is the only user-facing change. jcmd GC.heap_dump -generation=young triggers a young GC (mirroring the existing full GC trigger for live dumps, but we don't want full gc here which is expensive and may promote young objects or clear old->young refs), then walks and dump only objects in young regions. The total work is proportional to young GC cost, so should be usable in production, unlike full heap dumps. The resulting data is small compared to the full heap, just the used survivor space. I can already manually filter an hprof based on region info from VM.info, and I have used this to cut my GC pauses significantly in both cases I tried. In one case it was a metrics object that lived for the duration of a request and was unnecessarily huge, in another it was some queues which buffer incoming records for a few seconds before flushing. This shows the usefulness, but the method is clunky (custom tooling, non-atomic operations) and expensive (still need a full heap dump, which is often not tolerable in production, full heap dump is very large, can't even use a live heap dump as full GC is problematic as mentioned above). jcmd GC.heap_dump -generation=young would provide an efficient way to get this info which works seamlessly with existing tools, and the implementation is simple. Thanks, Oli (old thread where someone had a similar requirement: https://mail.openjdk.org/pipermail/hotspot-gc-dev/2013-August/008077.html) Amazon Development Centre (London) Ltd. Registered in England and Wales with registration number 04543232 with its registered office at 1 Principal Place, Worship Street, London EC2A 2FA, United Kingdom. Amazon Development Centre (London) Ltd. Registered in England and Wales with registration number 04543232 with its registered office at 1 Principal Place, Worship Street, London EC2A 2FA, United Kingdom.
