RFR: 8366865: Allocation GC Pauses Triggered after JVM has started shutdown [v7]

Jonas Norlinder duke at openjdk.org
Thu Sep 18 22:09:00 UTC 2025


On Thu, 18 Sep 2025 13:28:52 GMT, Ivan Walulya <iwalulya at openjdk.org> wrote:

>> Please review this patch to skip VM_GC_Collect_Operations  if initiated after the VM shutdown process has begun. We add a _is_shutting_down flag to CollectedHeap, which is set while holding the Heap_lock. This ensures mutual exclusion with VM_GC_Collect_Operations, which also require the Heap_lock.
>> 
>> Skipping VM_GC_Collect_Operation would otherwise cause allocation requests to fail (resulting in OutOfMemoryError) if requesting daemon threads were allowed to continue, we instead block these threads on a monitor. They remain stalled until they are terminated as part of the VM shutdown sequence.
>> 
>> Testing: Tier 1-7
>
> Ivan Walulya has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains 15 commits:
> 
>  - make universal
>  - Merge remote-tracking branch 'upstream/master' into shutting_down_gcs
>  - Merge remote-tracking branch 'upstream/master' into shutting_down_gcs
>  - Merge remote-tracking branch 'upstream/master' into shutting_down_gcs
>  - Revert
>  - Thomas Review
>  - return on timeout
>  - Merge remote-tracking branch 'upstream/master' into shutting_down_gcs
>  - timed wait
>  - Merge remote-tracking branch 'upstream/master' into shutting_down_gcs
>  - ... and 5 more: https://git.openjdk.org/jdk/compare/4c7c009d...1a53c207

src/hotspot/share/memory/universe.hpp line 132:

> 130: 
> 131:   // Shutdown
> 132:   static volatile bool _is_shutting_down;

If `_is_shutting_down` is in Universe, should ZGC/ZAbort hook into this too? It could be confusing that ZAbort reports that we are shutting down but the universe field does not report this. I would expect them both to report true.

src/hotspot/share/services/cpuTimeUsage.cpp line 39:

> 37: 
> 38: static inline jlong thread_cpu_time_or_zero(Thread* thread) {
> 39:   assert(!thread->has_terminated(), "Cannot get cpu time for terminated thread: %zu", thread->osthread()->thread_id_for_printing());

Are we sure that the thread is never in a de-allocated state here? I discussed adding an assert like that in `os::thread_cpu_time` but @dholmes-ora pointed out that such asserts are in general dangerous as the they may have been dealloacted and the assert itself could result in a segmentation fault. That being said, maybe we know that all threads we could possibly poke at here in this point could be terminated but not deallocated?

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

PR Review Comment: https://git.openjdk.org/jdk/pull/27190#discussion_r2361277250
PR Review Comment: https://git.openjdk.org/jdk/pull/27190#discussion_r2361281193


More information about the hotspot-dev mailing list