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.
