On Mon, 17 Jul 2023 04:11:54 GMT, David Holmes <dhol...@openjdk.org> wrote:
> > Because I need the overloaded check is_AttachListener_thread(), which can > > avoid using the VM thread to execute the dump file merge as much as > > possible. > > I'm unclear what the set of candidate threads is for executing the code that > does the `is_AttachListener_thread()` test. Can you not just use > `!thread->is_VM_thread()` to keep it out of the VMThread? Many types of threads can execute HeapDumper, such as JMX heapdump, GC HeapDumpOnOutOfMemoryError etc. To ensure safety, I want to make it clear that file merging should only be executed using the current thread as an attach listener thread. For other situations, it should be uniformly completed using the VM Thread. In addition, a potential optimization is that if flags such as HeapDumpOnOutOfMemoryError trigger heapdump, the triggerer does not need to wait for the merge to complete on site(because they are not in interactive mode). It only needs to generate separate files during STW and then specify the AttachListenerThread to complete the file merging operation using handshake. This requires us to have an AttachListenerThread class. For future extension considerations and for code readability and safety, I added an AttachListenerThread class. ------------- PR Comment: https://git.openjdk.org/jdk/pull/13667#issuecomment-1637424431
