Uploaded image for project: 'JDK'
  1. JDK
  2. JDK-8311599

GenShen: Missing card mark barrier when processing references

XMLWordPrintable

    • Icon: Bug Bug
    • Resolution: Fixed
    • Icon: P4 P4
    • None
    • repo-shenandoah
    • hotspot
    • gc

      Following crash was observed executing `eclipse` benchmark of dacapo suite:
      ```
      #
      # A fatal error has been detected by the Java Runtime Environment:
      #
      # Internal Error (/codebuild/output/src4279/src/s3/00/src/hotspot/share/oops/compressedOops.inline.hpp:140), pid=6003, tid=6042
      # assert(check_alignment(result)) failed: address not aligned: 0x00000008baadbabe
      #
      # JRE version: OpenJDK Runtime Environment (21.0) (fastdebug build 21-root-shenandoah-x86-template.389bb7)
      # Java VM: OpenJDK 64-Bit Server VM (fastdebug 21-root-shenandoah-x86-template.389bb7, mixed mode, sharing, compressed oops, compressed class ptrs, shenandoah gc, linux-amd64)
      # Core dump will be written. Default location: /codebuild/output/src156/src/s3/00/results/core.6003.%i
      #
      # An error report file with more information is saved as:
      # results/genshen/dacapo/1/hs_err_pid6003.log
      ```

      The command line was:
      ```
      java -XX:ErrorFile=results/genshen/dacapo/1/hs_err_pid%p.log -XX:-TieredCompilation -XX:+UseShenandoahGC -XX:+UnlockExperimentalVMOptions -XX:ShenandoahGCMode=generational -XX:-ShenandoahPacing -XX:+UnlockDiagnosticVMOptions -XX:-ShenandoahUncommit -Xms12g -Xmx12g -XX:+ShenandoahVerify -XX:+UnlockDiagnosticVMOptions -XX:+ShenandoahAllocFailureALot -javaagent:/tmp/jHiccup.jar=-l,results/genshen/dacapo/1/eclipse.jhiccup.log,-i,1000,-a -Xlog:async -Xlog:gc*=info,safepoint*=info,handshake*=info:results/genshen/dacapo/1/eclipse.jvm.log::filecount=0,filesize=0 -jar /tmp/dacapo-evaluation-git-0d047f55.jar --scratch-directory /tmp/dacapo-scratch/dacapo --no-validation --latency-csv --converge --variance 5 --log-directory /tmp/dacapo-scratch/eclipse eclipse
      ```
      Stack trace indicates a problem with remembered set scanning (perhaps problem for verifier itself):

      ```
      V [libjvm.so+0xad48b3] report_vm_error(char const*, int, char const*, char const*, ...)+0xf3
      V [libjvm.so+0x61a69c]
      V [libjvm.so+0x1816822] void ShenandoahVerifyOopClosure::do_oop_work<narrowOop>(narrowOop*)+0x132
      V [libjvm.so+0x1751af3] void InstanceRefKlass::oop_oop_iterate_discovery<narrowOop, OopIterateClosure, MrContains const>(oop, ReferenceType, OopIterateClosure*, MrContains const&)+0x103
      V [libjvm.so+0x1752150] void OopOopIterateBoundedDispatch<OopIterateClosure>::Table::oop_oop_iterate_bounded<InstanceRefKlass, narrowOop>(OopIterateClosure*, oop, Klass*, MemRegion)+0x5b0
      V [libjvm.so+0x17d137b] void ShenandoahScanRemembered<ShenandoahDirectCardMarkRememberedSet>::process_clusters<OopIterateClosure>(unsigned long, unsigned long, HeapWordImpl**, OopIterateClosure*, bool, unsigned int)+0x89b
      V [libjvm.so+0x17d2972] ShenandoahScanRemembered<ShenandoahDirectCardMarkRememberedSet>::roots_do(OopIterateClosure*)+0x272
      V [libjvm.so+0x17d0786] ShenandoahRootVerifier::roots_do(OopIterateClosure*)+0x266
      V [libjvm.so+0x1818225] ShenandoahVerifierReachableTask::work(unsigned int)+0x855
      ```

      When reference processing threads operate on the discovered list, they may create old-to-young pointers. Such pointers need to be recorded in the remembered set.

            wkemper William Kemper
            wkemper William Kemper
            Votes:
            0 Vote for this issue
            Watchers:
            3 Start watching this issue

              Created:
              Updated:
              Resolved: