On Tue, 12 Dec 2023 21:59:12 GMT, Alex Menkov <[email protected]> wrote:
>> Prior to the virtual thread changes what thread is performing the merge? >> After these changes what thread would do it if not included in the VM >> operation? >> >> The assert is correct - we should not do the merge at the safepoint (or even >> in the VMThread). > >> Prior to the virtual thread changes what thread is performing the merge? > > Prior the change merge is performed on either AttachListener thread (when > it's the current thread - special case for tools like jcmd) or on VMThread > (if the current thread is not AttachListener thread). > Note also that prior the change segmented dumping was conditional - if GC > supports multiple workers and if the caller requests parallel dump. > HeapDumpAfterFullGC/HeapDumpBeforeFullGC request dumping in 1 thread, so > there was no merge in the scenarios. > >> After these changes what thread would do it if not included in the VM >> operation? > > On the current thread. As I wrote before I 'm not sure if it can cause some > unexpected consequences in some cases. > I tried to do the change - tier1 passed (TestReduceAllocationAndHeapDump.java > test calls Runtime.gc() with HeapDumpAfterFullGC, merge is performed on main > java thread) Sorry, I was wrong. TestReduceAllocationAndHeapDump.java failed on the assert. I.e. merge is performed on main java thread, but VM is at safepoint ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/17040#discussion_r1424634783
