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).

src/hotspot/share/gc/shenandoah/shenandoahHeap.cpp line 3031:

> 3029: void ShenandoahHeap::initialize_diagnostic_worker(WorkerThread* thread) 
> {
> 3030:   ShenandoahThreadLocalData::initialize_gclab(thread);
> 3031: }

I really think it would be all-round easier to let diagnostic threads work 
without GCLABs, deferring to "shared" allocations. Saves a lifecycle head-ache, 
avoids the need for GCLAB flushes, etc.

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/33218#discussion_r4204915831

Reply via email to