JDK-8366865 : Allocation GC Pauses Triggered after JVM has started shutdown
  • Type: Enhancement
  • Component: hotspot
  • Sub-Component: gc
  • Priority: P4
  • Status: Resolved
  • Resolution: Fixed
  • Submitted: 2025-09-04
  • Updated: 2025-11-24
  • Resolved: 2025-09-23
The Version table provides details related to the release that this issue/RFE will be addressed.

Unresolved : Release in which this issue/RFE will be addressed.
Resolved: Release in which this issue/RFE has been resolved.
Fixed : Release in which this issue/RFE has been fixed. The release containing this fix may be available for download as an Early Access Release or a General Availability Release.

To download the current JDK release, click here.
JDK 26
26 b17Fixed
Related Reports
Causes :  
JDK-8368940 - Missing ResourceMark when stalling for shutdown
Causes :  
JDK-8371990 - Remove two second delayed OOME after GC shutdown
Causes :  
JDK-8371755 - Test java/lang/instrument/DaemonThread/TestDaemonThread.java failed
Duplicate :  
JDK-8366328 - G1: Crash on reading os::thread_cpu_time
Relates :  
JDK-8367902 - Allocation after Universe::before_exit() in the VM shutdown sequence
Relates :  
JDK-8371754 - Test vmTestbase/vm/mlvm/indy/func/jdi/breakpoint/Test.java hangs during VM exit
Relates :  
JDK-8366328 - G1: Crash on reading os::thread_cpu_time
Description
After JVM shutdown has begun, G1, Serial and Parallel may continue processing queued VM_GC_Collect_Operations. 

We should investigate whether these operations can be skipped once shutdown is in progress. Allowing them to proceed can be misleading, as the JVM prints a final heap summary during shutdown, yet continues performing GC activity afterward, which may confuse users reviewing the logs.

Sample log:
[1.360s][info ][cpu     ] === CPU time Statistics =============================================================
[1.360s][info ][cpu     ]                                                                             CPUs
[1.360s][info ][cpu     ]                                                                s       %  utilized
[1.360s][info ][cpu     ]    Process
[1.360s][info ][cpu     ]      Total                                                2.6865  100.00       2.0
[1.360s][info ][cpu     ]      Garbage Collection                                   2.1653   80.60       1.6
[1.360s][info ][cpu     ]        GC Threads                                         2.0561   76.54       1.5
[1.360s][info ][cpu     ]        VM Thread                                          0.1091    4.06       0.1
[1.360s][info ][cpu     ] =====================================================================================
[1.414s][info ][gc,exit ] Heap
[1.414s][info ][gc,exit ]  garbage-first heap   total reserved 32768K, committed 32768K, used 26280K [0x00000000fe000000, 0x0000000100000000)
[1.414s][info ][gc,exit ]   region size 1024K, 6 young (6144K), 1 survivors (1024K)
[1.414s][info ][gc,exit ]  Metaspace       used 327K, committed 512K, reserved 1114112K
[1.414s][info ][gc,exit ]   class space    used 17K, committed 128K, reserved 1048576K
[1.420s][trace][gc,alloc] Thread-18: Successfully scheduled collection returning 0x00000000ff200000
[1.427s][trace][gc,alloc] Thread-25: Successfully scheduled collection returning 0x00000000ff100000
[1.448s][trace][gc,alloc] Thread-74: Successfully scheduled collection returning 0x00000000ff400000
[1.448s][trace][gc,alloc] Thread-48: Unsuccessfully scheduled collection allocating 50002 words
[1.454s][trace][gc,alloc] Thread-62: Successfully scheduled collection returning 0x00000000ff400000
[1.461s][trace][gc,alloc] Thread-49: Successfully scheduled collection returning 0x00000000ff300000
[1.468s][trace][gc,alloc] Thread-79: Successfully scheduled collection returning 0x00000000ff400000
[1.474s][trace][gc,alloc] Thread-36: Successfully scheduled collection returning 0x00000000ff300000
[1.494s][trace][gc,alloc] Thread-70: Successfully scheduled collection returning 0x00000000ff400000
[1.500s][trace][gc,alloc] Thread-91: Successfully scheduled collection returning 0x00000000ff700000
Comments
Changeset: 3e5094ed Branch: master Author: Ivan Walulya <iwalulya@openjdk.org> Date: 2025-09-23 08:19:12 +0000 URL: https://git.openjdk.org/jdk/commit/3e5094ed12dbfad7587b85ae2168565682c1f1db
23-09-2025
A pull request was submitted for review. Branch: master URL: https://git.openjdk.org/jdk/pull/27190 Date: 2025-09-10 09:57:18 +0000
10-09-2025
Once shutdown tells the VMThread to terminate no more VM operations will be executed. Any in-progress VM operation must complete before the VMThread can terminate. Also we grab the heap-lock before shutting down the VMThread. // Stop VM thread. { // 4945125 The vm thread comes to a safepoint during exit. // GC vm_operations can get caught at the safepoint, and the // heap is unparseable if they are caught. Grab the Heap_lock // to prevent this. The GC vm_operations will not be able to // queue until after the vm thread is dead. After this point, // we'll never emerge out of the safepoint before the VM exits. // Assert that the thread is terminated so that acquiring the // Heap_lock doesn't cause the terminated thread to participate in // the safepoint protocol. assert(thread->is_terminated(), "must be terminated here"); MutexLocker ml(Heap_lock); VMThread::wait_for_vm_thread_exit();
10-09-2025