JDK-8038222 : Assembler::bsrl fails on assert when -UseCountLeadingZerosInstruction is used on CPU with LZCNT support
  • Type: Bug
  • Component: hotspot
  • Sub-Component: compiler
  • Affected Version: hs25,8u20,9
  • Priority: P2
  • Status: Resolved
  • Resolution: Fixed
  • OS: generic
  • CPU: x86
  • Submitted: 2014-03-24
  • Updated: 2019-09-13
  • Resolved: 2014-03-25
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.
8u20Resolved 9 b08Fixed
Assembler::bsrl fails on assert when -UseCountLeadingZerosInstruction is used on CPU with LZCNT support:

$JAVA_HOME/bin/java -XX:-UseCountLeadingZerosInstruction -Xcomp -server -XX:-TieredCompilation -version

# To suppress the following error report, specify this argument
# after -XX: or in .hotspotrc:  SuppressErrorAt=/assembler_x86.cpp:1115
# A fatal error has been detected by the Java Runtime Environment:
#  Internal Error (/opt/jprt/T/P1/171256.amurillo/s/hotspot/src/cpu/x86/vm/assembler_x86.cpp:1115), pid=1265, tid=2938628976
#  assert(!VM_Version::supports_lzcnt()) failed: encoding is treated as LZCNT
# JRE version: Java(TM) SE Runtime Environment (9.0) (build 1.9.0-internal-fastdebug-201403211712.amurillo.jdk9-hs-2014-03-21-b00)
# Java VM: Java HotSpot(TM) Server VM (25.0-b62-fastdebug compiled mode linux-x86 )
# Failed to write core dump. Core dumps have been disabled. To enable core dumping, try "ulimit -c unlimited" before starting Java again
# An error report file with more information is saved as:
# /export/fzhinkin/test/hs_err_pid1265.log
# Compiler replay data is saved as:
# /export/fzhinkin/test/replay_pid1265.log
# If you would like to submit a bug report, please visit:
#   http://bugreport.sun.com/bugreport/crash.jsp
---------------  T H R E A D  ---------------

Current thread (0xaf9f7c00):  JavaThread "C2 CompilerThread1" daemon [_thread_in_native, id=1299, stack(0xaf1fe000,0xaf27f000)]

Stack: [0xaf1fe000,0xaf27f000],  sp=0xaf27c270,  free space=504k
Native frames: (J=compiled Java code, j=interpreted, Vv=VM code, C=native code)
V  [libjvm.so+0xdeb745]  VMError::report_and_die()+0x185
V  [libjvm.so+0x5ef238]  report_vm_error(char const*, int, char const*, char const*)+0x68
V  [libjvm.so+0x31506d]  Assembler::bsrl(RegisterImpl*, RegisterImpl*)+0x4d
V  [libjvm.so+0x1d50f8]  countLeadingZerosI_bsrNode::emit(CodeBuffer&, PhaseRegAlloc*) const+0xe8
V  [libjvm.so+0x563cb1]  Compile::scratch_emit_size(Node const*)+0x441
V  [libjvm.so+0xa88885]  MachNode::size(PhaseRegAlloc*) const+0x55
V  [libjvm.so+0xbc62d9]  Compile::shorten_branches(unsigned int*, int&, int&, int&)+0x2a9
V  [libjvm.so+0xbc6fa9]  Compile::init_buffer(unsigned int*)+0x2b9
V  [libjvm.so+0xbce4b1]  Compile::Output()+0x4a1
V  [libjvm.so+0x5701d1]  Compile::Code_Gen()+0x431
V  [libjvm.so+0x57359d]  Compile::Compile(ciEnv*, C2Compiler*, ciMethod*, int, bool, bool, bool)+0x1a3d
V  [libjvm.so+0x45aa1b]  C2Compiler::compile_method(ciEnv*, ciMethod*, int)+0x2fb
V  [libjvm.so+0x580ce9]  CompileBroker::invoke_compiler_on_method(CompileTask*)+0xbf9
V  [libjvm.so+0x5824cd]  CompileBroker::compiler_thread_loop()+0x61d
V  [libjvm.so+0xd648ff]  compiler_thread_entry(JavaThread*, Thread*)+0x4f
V  [libjvm.so+0xd73024]  JavaThread::thread_main_inner()+0x234
V  [libjvm.so+0xd733c4]  JavaThread::run()+0x2e4
V  [libjvm.so+0xbaf419]  java_start(Thread*)+0x119
C  [libpthread.so.0+0x6b39]  start_thread+0xc9
C  [libc.so.6+0xe2d6e]  clone+0x5e

Issue could be reproduced with HotSpot build with JDK-8031321 fix.
The assert is actually too strong. Shouldn't be a problem in product.

ILW=Crash, Not Likely, No workaround=HLH=P2