JDK-8274007 : [REDO] VM Exit does not abort concurrent mark
  • Type: Bug
  • Component: hotspot
  • Sub-Component: gc
  • Affected Version: 18
  • Priority: P3
  • Status: Resolved
  • Resolution: Fixed
  • Submitted: 2021-09-20
  • Updated: 2022-09-06
  • Resolved: 2022-01-13
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 18 JDK 19
18 b32Fixed 19Fixed
Related Reports
Relates :  
JDK-8273940 - vmTestbase/vm/mlvm/meth/stress/gc/callSequencesDuringGC/Test.java crashes in full gc during VM exit
Relates :  
JDK-8273605 - VM Exit does not abort concurrent mark
Relates :  
JDK-8291725 - Leftover marks when VM shutdown aborts bitmap clearing make mixed gc fail
Relates :  
JDK-8293431 - G1: Investigate stalling allocating threads during shutdown instead of doing GC
Description
JDK-8273605 introduced some change to early abort concurrent operation when the VM is about to exit. However this caused fairly frequent crashes in JDK-8273940 that were traced back to JDK-8273605. JDK-8273940 reverted that change.

The task is to try again implementing concurrent mark abort at exit as indicated by JDK-8273605.
Comments
Changeset: 33814791 Author: Thomas Schatzl <tschatzl@openjdk.org> Date: 2022-01-13 08:42:17 +0000 URL: https://git.openjdk.java.net/jdk18u/commit/33814791d917b0c09909bf19b432dd8dfc6cd9db
25-01-2022
Changeset: 33814791 Author: Thomas Schatzl <tschatzl@openjdk.org> Date: 2022-01-13 08:42:17 +0000 URL: https://git.openjdk.java.net/jdk/commit/33814791d917b0c09909bf19b432dd8dfc6cd9db
18-01-2022
Changeset: 33814791 Author: Thomas Schatzl <tschatzl@openjdk.org> Date: 2022-01-13 08:42:17 +0000 URL: https://git.openjdk.java.net/jdk18/commit/33814791d917b0c09909bf19b432dd8dfc6cd9db
13-01-2022
Log output of a crash confirms this: ### TRACE 1: TEST PASSED [1.284s][info][gc ] stop-service // debug log message printed in CollectedHeap::stop() [1.284s][info][gc,start] GC(17) Pause Full (System.gc()) There are a few more related asserts firing - we simply can not set has_aborted at any time.
06-12-2021
The problem with the original change is (I think) that setting the _has_aborted flag can interfere with Full GC operation. In particular, it causes the next bitmap to be not cleared during G1ConcurrentMark::concurrent_cycle_abort() called by Full GC. So if the VM-exit call that stops the threads happens just before a full gc (and before actual VM exit), the former sets _has_aborted, the next bitmap is not cleared properly at Full GC start, and so the full gc operation gets confused.
06-12-2021