On Wed, 14 Oct 2026 09:06:37 GMT, Stefan Karlsson <[email protected]> wrote:
>> ### Summary >> For Shenandoah and ZGC, safepoint workers were created at startup and only >> used for heap dump and heap inspection. If heap dump or heap inspection >> never runs, these threads consume memory without doing any work. For G1 and >> Parallel, GC pauses and non-GC safepoints share the GC worker pool, so heap >> dump and heap inspection don't need a separate worker pool. The downside is >> that dump and inspection work contributes to GC CPU time, which can affect >> how G1 sizes its heap. >> >> ### Changes >> Safepoint workers are replaced with a diagnostic worker pool used by heap >> dump and heap inspection. The diagnostic worker pool is created on the first >> heap dump or heap inspection that requests more than one thread, if the >> collector supports parallel heap iteration and >> `os::initial_active_processor_count()` > 1. The pool holds at most >> `os::initial_active_processor_count()` workers, and workers stay alive until >> the VM exits. >> >> G1 and Parallel no longer lend their GC worker pool. ZGC's `ZRuntimeWorkers` >> is deleted because it's no longer used. For Shenandoah, diagnostic workers >> have no GCLAB and fall back to shared allocation when they evacuate objects. >> >> ### Testing all passed >> - linux-x86_64-server-fastdebug: `hotspot:tier1_gc`, >> `hotspot:tier1_serviceability`, `gc/shenandoah` >> - GHA >> - Internal CI pipeline >> >> --------- >> - [x] I confirm that I make this contribution in accordance with the >> [OpenJDK Interim AI Policy](https://openjdk.org/legal/ai). > > I would have expected this PR to completely move the diagnostic threads out > of the GC code and into the serviceability part of the JVM. > > So: > 1) Stop using ParallelGCThreads to drive thread counts for serviceability > features > 2) Move DiagnosticWorkers out of the GC > 3) Don't apply GCThreadClosure to these threads. @stefank 1. I think we still need to keep `CollectedHeap::supports_parallel_heap_iteration()`. Other than the fact that Serial GC strictly runs on a single thread, it doesn't implement `parallel_object_iterator` which dump / inspection uses to walk the heap with multiple threads. If we removed this condition, then the VM would crash when more than one worker is requested. 2. Yes, that's right. The error reporter can read the worker pool outside a safepoint. I'll add some comments to explain the atomic operations. ------------- PR Comment: https://git.openjdk.org/jdk/pull/33218#issuecomment-6197448418
