JDK-8254695 : G1: Next mark bitmap clear not cancelled after marking abort
  • Type: Bug
  • Component: hotspot
  • Sub-Component: gc
  • Affected Version: 16
  • Priority: P5
  • Status: Resolved
  • Resolution: Fixed
  • Submitted: 2020-10-13
  • Updated: 2020-10-22
  • Resolved: 2020-10-16
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 16
16 b21Fixed
Related Reports
Blocks :  
Description
Next mark bitmap clearing is supposed to abort after a concurrent mark abort. It does not because the condition is wrong.

I.e. the current code

        // Abort iteration if after yielding the marking has been aborted.
        if (_cm != NULL && _cm->do_yield_check() && _cm->has_aborted()) {
          return true;
        }

is wrong. Correct code is:

if (_cm != NULL) {
  _cm->do_yield_check();
  if (_cm->has_aborted) {
    return true;
  }
}

Currently this has no impact except for wasted time. However with JDK-8253600 it will clear the prev bitmap containing liveness information (previously passed as next bitmap into the task) as the full gc will first update the next bitmap and then swap bitmaps.
Comments
Changeset: 1742c44a Author: Thomas Schatzl <tschatzl@openjdk.org> Date: 2020-10-16 09:19:22 +0000 URL: https://git.openjdk.java.net/jdk/commit/1742c44a
16-10-2020

It looks like I observed above case in some perf run with some upcoming heap resizing and uncommit changes: # # A fatal error has been detected by the Java Runtime Environment: # # SIGSEGV (0xb) at pc=0x00007fe40fe859b4, pid=105462, tid=105736 # # JRE version: Java(TM) SE Runtime Environment (16.0) (build 16-internal+0-2020-10-13-0836573.thomas.schatzl.jdk-mach5) # Java VM: Java HotSpot(TM) 64-Bit Server VM (16-internal+0-2020-10-13-0836573.thomas.schatzl.jdk-mach5, mixed mode, sharing, tiered, compressed oops, g1 gc, linux-amd64) # Problematic frame: # C [libc.so.6+0x8f9b4] __memset_sse2+0x54 # # Core dump will be written. Default location: Core dumps may be processed with "/usr/libexec/abrt-hook-ccpp %s %c %p %u %g %t e %P %I %h" (or dumping to /mnt/aurora/aurora/sandbox/microbenchmarks/core.105462) # # If you would like to submit a bug report, please visit: # https://bugreport.java.com/bugreport/crash.jsp # --------------- S U M M A R Y ------------ Command Line: -Djava.library.path=. -XX:+IgnoreUnrecognizedVMOptions -XX:CompileCommandFile=/tmp/jmh12384866330653739304compilecommand org.openjdk.jmh.runner.ForkedMain 127.0.0.1 40355 Host: Intel(R) Xeon(R) Platinum 8167M CPU @ 2.00GHz, 104 cores, 754G, Oracle Linux Server release 7.7 Time: Tue Oct 13 14:13:03 2020 UTC elapsed time: 582.125488 seconds (0d 0h 9m 42s) --------------- T H R E A D --------------- Current thread (0x00007fe39c005b60): ConcurrentGCThread "G1 Conc#8" [stack: 0x00007fe13fbfa000,0x00007fe13fcfa000] [id=105736] Stack: [0x00007fe13fbfa000,0x00007fe13fcfa000], sp=0x00007fe13fcf8d18, free space=1019k Native frames: (J=compiled Java code, A=aot compiled Java code, j=interpreted, Vv=VM code, C=native code) C [libc.so.6+0x8f9b4] __memset_sse2+0x54 V [libjvm.so+0xa8fd1d] MarkBitMap::do_clear(MemRegion, bool)+0x6d V [libjvm.so+0x6498a2] G1ClearBitMapTask::G1ClearBitmapHRClosure::do_heap_region(HeapRegion*)+0x52 V [libjvm.so+0x727920] HeapRegionManager::par_iterate(HeapRegionClosure*, HeapRegionClaimer*, unsigned int) const+0x90 V [libjvm.so+0x6497f5] G1ClearBitMapTask::work(unsigned int)+0x65 V [libjvm.so+0xd88f0f] GangWorker::loop()+0x5f V [libjvm.so+0xcee9dd] Thread::call_run()+0xfd V [libjvm.so+0xb44fc7] thread_native_entry(Thread*)+0xe7 siginfo: si_signo: 11 (SIGSEGV), si_code: 2 (SEGV_ACCERR), si_addr: 0x00007fe3c75c5000
13-10-2020

Actually this can be a problem if the full gc uncommits parts of the mark bitmap that the concurrent mark is going to clear after that full gc.
13-10-2020