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

-XX:+PrintBiasedLockingStatistics causes crash during initialization on Windows platforms

    Details

    • Subcomponent:
    • Resolved In Build:
      b01
    • CPU:
      x86
    • OS:
      windows

      Backports

        Description

        Reported by : chengjingwei1@huawei.com

        The JVM crashes during initialization on 64-bit Windows platforms when running the following command:
        java -XX:+UnlockDiagnosticVMOptions -XX:+PrintBiasedLockingStatistics -version

        The crash would happen with Oracle JDK 11+ and AdoptOpenJDK 11+ (both compiled with VS2017).

        OS version:
        Windows 7 Professional SP1 x64 / Windows Server 2012 R2 Datacenter x64

        For Oracle JDK 11+,

        Java version:
        java version "11.0.3" 2019-04-16 LTS
        Java(TM) SE Runtime Environment 18.9 (build 11.0.3+12-LTS)
        Java HotSpot(TM) 64-Bit Server VM 18.9 (build 11.0.3+12-LTS, mixed mode)

        Crash message:
        #
        # A fatal error has been detected by the Java Runtime Environment:
        #
        # Internal Error (macroAssembler_x86.hpp:116), pid=20940, tid=19804
        # guarantee(this->is8bit(imm8)) failed: Short forward jump exceeds 8-bit offset
        #
        # JRE version: (11.0.3+12) (build )
        # Java VM: Java HotSpot(TM) 64-Bit Server VM (11.0.3+12-LTS, mixed mode, tiered, compressed oops, g1 gc, windows-amd64)
        # No core dump will be written. Minidumps are not enabled by default on client versions of Windows
        #
        # An error report file with more information is saved as:
        # D:\jdk\jdk-11.0.3\bin\hs_err_pid20940.log
        #
        # If you would like to submit a bug report, please visit:
        # http://bugreport.java.com/bugreport/crash.jsp
        #

        We built openjdk jdk8u with VS2017 and could also reproduce this issue using this build.

        Some quick analysis for jdk8u:

        The crash happens when macroAssembler is generating "zerolocals_synchronized".

        In hotspot/src/cpu/x86/vm/macroAssembler.cpp, there's a label named "try_revoke_bias", which is to be binded with a short jump.

            1) If PrintBiasedLockingStatistics is turned on, jvm would generate some extra instructions for tracking the counters.

            If ASLR is turned on when compiling hotspot (which is the default behaviour in VS2017), then
            2) The distance between BiasedLockCounter and current pc can be larger than 4G, causing MacroAssembler::atomic_incl to
        generate an extra lea instruction;

            3) Universe::narrow_klass_shift() could be zero, causing MacroAssembler::decode_klass_not_null to generate some extra
        instructions.

            If all the above conditions are met, try_revoke_bias would consume more than 127 bytes, triggering the assert and crashing
        the jvm.

          Attachments

            Issue Links

              Activity

                People

                • Assignee:
                  jnordstrom Joakim Nordstrom
                  Reporter:
                  fyang Fei Yang
                • Votes:
                  0 Vote for this issue
                  Watchers:
                  5 Start watching this issue

                  Dates

                  • Created:
                    Updated:
                    Resolved: