On Wed, 14 Oct 2026 21:11:15 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 >> `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). > > Patrick Fontanilla has updated the pull request incrementally with one > additional commit since the last revision: > > Add epsilon test Thanks for taking the extra time to move this out of the GC code. Two more questions: 1) Do we really need to keep `CollectedHeap::supports_parallel_heap_iteration()` ? I understand that this causes JVMs running with the Serial GC to run with single-threaded heap inspection, but is forcing that via the selection of GC really necessary? Isn't it the case that Serial GC is typically run on smaller setups, and for those setups we would likely select a very small number of diagnostic worker threads anyways? It would be really nice to get rid of this coupling. 2) There's a release_store when worker threads are created, and it is not obvious why that is needed. My guess is that this has been added just for the error reporter, that could be calling a diagnostic_threads_do while safepoint VM operation is in progress? Other use-cases of _workers seems to be handled by our normal VM Operation / safepoint coordination, and there the release_store/load_acquire is not needed. If this is needed because of the error reporting, could you add a comment to the release_store and load_acquire explaining this? ------------- PR Review: https://git.openjdk.org/jdk/pull/33218#pullrequestreview-5530527589
