RFR: 8327864: Support segmented heap dump for HotSpotDiagnosticMXBean
Kevin Walls
kevinw at openjdk.org
Wed Mar 13 20:08:36 UTC 2024
On Tue, 12 Mar 2024 07:59:12 GMT, Yi Yang <yyang at openjdk.org> wrote:
> We've received feedback from users of cloud APM platform wanting the new version of the JDK to allow the HotSpotDiagnosticMXBean.dumpHeap underpinnings to reduce STW time using sgemented heapdump. Supporting segmented heapdump for mxbean is a reasonable requirement and adds little additional complexity, both in terms of maintainability and understanding.
Hi!
Segmented is an awkward term as we use that word inside hprof too. For the previous change we used the phrase "two phase" as well as calling it segmented, which I think helps.
Also this change means jmm_DumpHeap will always use HeapDumper::default_num_of_dump_threads().
That's not a bad thing, but could the bug title be something like "Enable two-phase heap dump for HotSpotDiagnosticMXBean (JMX)" ? I think then it's clearer what's happening just from the title.
+ if (current_thread->is_AttachListener_thread() || !_oome) {
I think "!_oome" here means "we are called from JMX" ? We should clarify. 8-) Trying to suggest a way of describing this.
// Operating in attach listener or called by management library:
// perform heapdump file merge operation in the current thread, preventing us
// from occupying the VM Thread, which in turn affects the occurrence of
// GC and other VM operations.
So the other case is only HeapDumpOnOutOfMemoryError processing, where we do the merge in a VM operation? Just checking if that's all agreed. 8-)
-------------
PR Review: https://git.openjdk.org/jdk/pull/18221#pullrequestreview-1935100384
More information about the serviceability-dev
mailing list