As far as I can tell, there's no reason why it must be the VM thread that takes on the task of writing the header, iterating over roots, etc. So, in VM_HeapDumper::work(), instead of checking if the current thread is the VM thread we can just check if the worker_id is non-zero. That way, a single worker thread will take on the task of writing the header, iterating over roots, etc, and all other worker threads will continue to call worker_loop().
Something like this:
diff --git a/src/hotspot/share/services/heapDumper.cpp b/src/hotspot/share/services/heapDumper.cpp
index ac5294aa2bd..0d3cfbd99d7 100644
--- a/src/hotspot/share/services/heapDumper.cpp
+++ b/src/hotspot/share/services/heapDumper.cpp
@@ -1771,7 +1771,7 @@ void VM_HeapDumper::doit() {
if (gang == NULL) {
work(0);
} else {
- gang->run_task(this, gang->active_workers(), true);
+ gang->run_task(this);
}
// Now we clear the global variables, so that a future dumper can run.
@@ -1780,7 +1780,7 @@ void VM_HeapDumper::doit() {
}
void VM_HeapDumper::work(uint worker_id) {
- if (!Thread::current()->is_VM_thread()) {
+ if (worker_id != 0) {
writer()->writer_loop();
return;
}
- relates to
-
JDK-8273559 Shenandoah: Shenandoah should support multi-threaded heap dump
-
- Resolved
-
-
JDK-8273639 tests fail with "assert(_handle_mark_nesting > 1) failed: memory leak: allocating handle outside HandleMark"
-
- Resolved
-