On Tue, 2 Apr 2024 21:13:33 GMT, Alex Menkov <amen...@openjdk.org> wrote:
>> The fix updated HeapDumper to always perform merge on the current thread. >> >> Testing: tier1-5, all HeapDump-related tests >> Covered heap dumping scenarios: >> - `jcmd GC.heap_dump` command; >> - `HotSpotDiagnosticMXBean.dumpHeap()`; >> - `HeapDumpBeforeFullGC`, `HeapDumpAfterFullGC` VM options; >> - `HeapDumpOnOutOfMemoryError` VM option. > > Alex Menkov has updated the pull request incrementally with one additional > commit since the last revision: > > comment Are we saying there is never any need to perform the merge in a VM Operation? Originally (JDK-8306441) it's either done in the attach thread, or a VM operation if we are in another thread. But maybe that was just being cautious. Keeping only the invoking thread busy, rather than a VM Operation, sounds like a good goal. I'm interested in if we can hit a problem by causing multiple heap dumps at once, e.g. jcmd, the app calling the MXBean, and maybe even the OnOOM trigger as well, could all happen at the same time. 8-) Using the MXBean, we may be able to make multiple heap dumps concurrently (either multiple MXBean invocations, or one MXBean invocation while a jcmd runs...). jcmd keeps the atttach listener thread busy, so we can't have concurrent dumps from that method. I think that explains the original code, where all other methods use the VM Operation. ------------- PR Review: https://git.openjdk.org/jdk/pull/18571#pullrequestreview-1976273140
