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.