JDK-8160360 : Mismatched field loads are folded in LoadNode::Value
  • Type: Bug
  • Component: hotspot
  • Sub-Component: compiler
  • Affected Version: 8,8u212,9
  • Priority: P2
  • Status: Closed
  • Resolution: Fixed
  • Submitted: 2016-06-27
  • Updated: 2019-08-22
  • Resolved: 2016-07-06
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 9
9 b131Fixed
Related Reports
Relates :  
JDK-8152590 - C2: @Stable support doesn't always work w/ incremental inlining
Relates :  
JDK-8157726 - VarHandles/Unsafe should support sub-word atomic ops
Sub Tasks
JDK-8160690 :  
Quarantine VarHandles tests - Resolved
JDK-8160971 :  
Re-enable VarHandle tests quarantined by JDK-8160690 - Resolved
Description
Current thread (0x0000007f80189000):  JavaThread "C2 CompilerThread2" daemon [_thread_in_native, id=6458, stack(0x0000007f50ced000,0x0000007f50ded000)]


Current CompileTask:
C2:   4778  671       4       java.lang.invoke.LambdaForm$BMH/1460779888::reinvoke (34 bytes)

Stack: [0x0000007f50ced000,0x0000007f50ded000],  sp=0x0000007f50de7250,  free space=1000k
Native frames: (J=compiled Java code, j=interpreted, Vv=VM code, C=native code)
V  [libjvm.so+0x1093710]  VMError::report(outputStream*, bool)+0x1780
V  [libjvm.so+0x1093d64]  VMError::report_and_die(int, char const*, char const*, std::__va_list, Thread*, unsigned char*, void*, void*, char const*, int, unsigned long)+0x140
V  [libjvm.so+0x109496c]  VMError::report_and_die(Thread*, char const*, int, char const*, char const*, std::__va_list)+0x54
V  [libjvm.so+0x6b7234]  report_vm_error(char const*, int, char const*, char const*, ...)+0xe0
V  [libjvm.so+0x102f1c8]  Type::make_constant_from_field(ciField*, ciInstance*, BasicType, bool)+0x3e8
V  [libjvm.so+0xcd7868]  LoadNode::Value(PhaseGVN*) const+0x8a8
V  [libjvm.so+0xe546e8]  PhaseGVN::transform_no_reclaim(Node*)+0x140
V  [libjvm.so+0x8ad700]  GraphKit::make_load(Node*, Node*, Type const*, BasicType, int, MemNode::MemOrd, LoadNode::ControlDependency, bool, bool, bool)+0xd4
V  [libjvm.so+0xbdd5dc]  LibraryCallKit::inline_unsafe_access(bool, BasicType, LibraryCallKit::AccessKind, bool)+0x940
V  [libjvm.so+0xbf3858]  LibraryIntrinsic::generate(JVMState*)+0x94
V  [libjvm.so+0x745f58]  Parse::do_call()+0x388
V  [libjvm.so+0xe2732c]  Parse::do_one_bytecode()+0x2ee0
V  [libjvm.so+0xe1a5b8]  Parse::do_one_block()+0x440
V  [libjvm.so+0xe1a958]  Parse::do_all_blocks()+0x108
V  [libjvm.so+0xe1d6ac]  Parse::Parse(JVMState*, ciMethod*, float)+0xac4
V  [libjvm.so+0x4a8c30]  ParseGenerator::generate(JVMState*)+0xc0
V  [libjvm.so+0x745f58]  Parse::do_call()+0x388
V  [libjvm.so+0xe2732c]  Parse::do_one_bytecode()+0x2ee0
V  [libjvm.so+0xe1a5b8]  Parse::do_one_block()+0x440
V  [libjvm.so+0xe1a958]  Parse::do_all_blocks()+0x108
V  [libjvm.so+0xe1d6ac]  Parse::Parse(JVMState*, ciMethod*, float)+0xac4
V  [libjvm.so+0x4a8c30]  ParseGenerator::generate(JVMState*)+0xc0
V  [libjvm.so+0x745f58]  Parse::do_call()+0x388
V  [libjvm.so+0xe2732c]  Parse::do_one_bytecode()+0x2ee0
V  [libjvm.so+0xe1a5b8]  Parse::do_one_block()+0x440
V  [libjvm.so+0xe1a958]  Parse::do_all_blocks()+0x108
V  [libjvm.so+0xe1d6ac]  Parse::Parse(JVMState*, ciMethod*, float)+0xac4
V  [libjvm.so+0x4a8c30]  ParseGenerator::generate(JVMState*)+0xc0
V  [libjvm.so+0x745f58]  Parse::do_call()+0x388
V  [libjvm.so+0xe2732c]  Parse::do_one_bytecode()+0x2ee0
V  [libjvm.so+0xe1a5b8]  Parse::do_one_block()+0x440
V  [libjvm.so+0xe1a958]  Parse::do_all_blocks()+0x108
V  [libjvm.so+0xe1d6ac]  Parse::Parse(JVMState*, ciMethod*, float)+0xac4
V  [libjvm.so+0x4a8c30]  ParseGenerator::generate(JVMState*)+0xc0
V  [libjvm.so+0x745f58]  Parse::do_call()+0x388
V  [libjvm.so+0xe2732c]  Parse::do_one_bytecode()+0x2ee0
V  [libjvm.so+0xe1a5b8]  Parse::do_one_block()+0x440
V  [libjvm.so+0xe1a958]  Parse::do_all_blocks()+0x108
V  [libjvm.so+0xe1d6ac]  Parse::Parse(JVMState*, ciMethod*, float)+0xac4
V  [libjvm.so+0x4a8c30]  ParseGenerator::generate(JVMState*)+0xc0
V  [libjvm.so+0x633a98]  Compile::Compile(ciEnv*, C2Compiler*, ciMethod*, int, bool, bool, bool, DirectiveSet*)+0xb38
V  [libjvm.so+0x4a745c]  C2Compiler::compile_method(ciEnv*, ciMethod*, int, DirectiveSet*)+0x150
V  [libjvm.so+0x63ecd0]  CompileBroker::invoke_compiler_on_method(CompileTask*)+0x314
V  [libjvm.so+0x63f83c]  CompileBroker::compiler_thread_loop()+0x2c8
V  [libjvm.so+0x100f6ec]  JavaThread::thread_main_inner()+0x1fc
V  [libjvm.so+0x100f938]  JavaThread::run()+0x1c0
V  [libjvm.so+0xdcb308]  thread_native_entry(Thread*)+0x118
C  [libpthread.so.0+0x7e2c]  start_thread+0xb0
C  [libc.so.6+0xc8430]  clone+0x70
Comments
If this bug was introduced by JDK-8152590 it is not a blocker. The links above says it is also related to JDK-8157726 which has not escaped jdk9/hs yet and could mean that this is a blocker after all. How much related to JDK-8157726 is it?
30-06-2016
Introduced by JDK-8152590.
28-06-2016
Only VarHandle tests for sub-word operations fail. Most likely, caused by JDK-8157726. The assert is hit only on linux-aarch64 & solaris-sparc.
28-06-2016