On Tue, 6 Oct 2026 00:25:32 GMT, Patrick Fontanilla <[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 `ParallelGCThreads` > 1. The > pool holds at most `ParallelGCThreads` 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. ------------- PR Comment: https://git.openjdk.org/jdk/pull/33218#issuecomment-6164851814
