RFR: JDK-8322042: HeapDumper should perform merge on the current thread instead of VMThread [v2]

[Kevin Walls]

On Tue, 2 Apr 2024 21:13:33 GMT, Alex Menkov <amenkov at 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