JDK-8193699 : AArch64: Fails to build after 8167372
  • Type: Bug
  • Component: hotspot
  • Sub-Component: compiler
  • Affected Version: 10
  • Priority: P1
  • Status: Closed
  • Resolution: Fixed
  • OS: linux
  • CPU: aarch64
  • Submitted: 2017-12-18
  • Updated: 2018-03-27
  • Resolved: 2017-12-26
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 10 JDK 11
10 b38Fixed 11Fixed
Related Reports
Relates :  
JDK-8191227 - Unsafe handle resolution in ConstantOopWriteValue::write_on() / print_on() and LIR_Assembler::jobject2reg()
Relates :  
JDK-8167372 - Add code to check for getting oops while thread is in native
Relates :  
JDK-8200290 - Scratch buffer creation fails with "assert(!current_thread_in_native()) failed: must not be in native" on SPARC
Description
Aarch64 builds are failing, with the following backtrace:

JDK-8167372 added a assertion that is tripping in the compiler:

Stack: [0x0000010003580000,0x0000010003780000],  sp=0x000001000377cab0,  free space=2034k
Native frames: (J=compiled Java code, A=aot compiled Java code, j=interpreted, Vv=VM code, C=native code)
V  [libjvm.so+0x11b624c]  VMError::report_and_die(int, char const*, char const*, std::__va_list, Thread*, unsigned char*, void*, void*, char const*, int, unsigned long)+0x658
V  [libjvm.so+0x11b5b04]  VMError::report_and_die(Thread*, char const*, int, char const*, char const*, std::__va_list)+0x84
V  [libjvm.so+0x822c88]  report_vm_error(char const*, int, char const*, char const*, ...)+0x110
V  [libjvm.so+0x62f448]  oopDesc* JNIHandles::resolve_impl<false>(_jobject*)+0xbc
V  [libjvm.so+0x63ab24]  JNIHandles::resolve(_jobject*)+0x34
V  [libjvm.so+0xdb4f14]  MacroAssembler::movoop(RegisterImpl*, _jobject*, bool)+0x88
V  [libjvm.so+0x54b120]  LIR_Assembler::jobject2reg(_jobject*, RegisterImpl*)+0x70
V  [libjvm.so+0x54c364]  LIR_Assembler::const2reg(LIR_OprDesc*, LIR_OprDesc*, LIR_PatchCode, CodeEmitInfo*)+0x2f4
V  [libjvm.so+0x5481a4]  LIR_Assembler::move_op(LIR_OprDesc*, LIR_OprDesc*, BasicType, LIR_PatchCode, CodeEmitInfo*, bool, bool, bool)+0x2e8
V  [libjvm.so+0x547248]  LIR_Assembler::emit_op1(LIR_Op1*)+0x1bc
V  [libjvm.so+0x539780]  LIR_Op1::emit_code(LIR_Assembler*)+0x2c
V  [libjvm.so+0x546468]  LIR_Assembler::emit_lir_list(LIR_List*)+0x17c
V  [libjvm.so+0x5462c4]  LIR_Assembler::emit_block(BlockBegin*)+0x1a8
V  [libjvm.so+0x5460a8]  LIR_Assembler::emit_code(BlockList*)+0x68
V  [libjvm.so+0x4e8524]  Compilation::emit_code_body()+0x150
V  [libjvm.so+0x4e8844]  Compilation::compile_java_method()+0x240
V  [libjvm.so+0x4e8bac]  Compilation::compile_method()+0xe4
V  [libjvm.so+0x4e9334]  Compilation::Compilation(AbstractCompiler*, ciEnv*, ciMethod*, int, BufferBlob*, DirectiveSet*)+0x24c
V  [libjvm.so+0x4ef4c4]  Compiler::compile_method(ciEnv*, ciMethod*, int, DirectiveSet*)+0xec
V  [libjvm.so+0x7a98e0]  CompileBroker::invoke_compiler_on_method(CompileTask*)+0x6d0
V  [libjvm.so+0x7a8754]  CompileBroker::compiler_thread_loop()+0x274
V  [libjvm.so+0x1117dec]  compiler_thread_entry(JavaThread*, Thread*)+0x94
V  [libjvm.so+0x1111fa8]  JavaThread::thread_main_inner()+0x184
V  [libjvm.so+0x1111dfc]  JavaThread::run()+0x18c
V  [libjvm.so+0xeffa38]  thread_native_entry(Thread*)+0x18c
C  [libpthread.so.0+0x7c50]  start_thread+0xb0
C  [libc.so.6+0xdac60]  thread_start+0x30

This causes debug builds to fail (fastdebug and slowdebug).
Comments
Running with JTreg with fast-debug mode, I get the following result: Test results: passed: 1,610; failed: 21 The failures are setup issues, and there are no errors or crashes, so I'd say the patch is as good, and ready for review.
21-12-2017
The second patch fixed the builds - I can now build to completion. I'll now run JTReg for hotspot and report back.
21-12-2017
ILW = Build failure; only for aarch64 debug build; none = HMH = P1
21-12-2017
> Trying usage of 'ThreadInVMfromUnknown' in place of 'ThreadInVMfromNative' tired in initial patch
21-12-2017
I've tried it, and unfortunately I still get a failure: {noformat} # Internal Error (/home/stuart/repos/hs/src/hotspot/share/runtime/interfaceSupport.hpp:181), pid=31444, tid=31445 # assert(thread->thread_state() == _thread_in_native) failed: coming from wrong thread state {noformat} It is happening from within the executing thread, rather than the compiler thread this time. It is prompted by the generation of a native wrapper.
20-12-2017
Possible fix - --- old/src/hotspot/cpu/aarch64/macroAssembler_aarch64.cpp 2017-12-20 04:50:36.790451772 -0800 +++ new/src/hotspot/cpu/aarch64/macroAssembler_aarch64.cpp 2017-12-20 04:50:36.392415694 -0800 @@ -3742,13 +3742,16 @@ } void MacroAssembler::set_narrow_oop(Register dst, jobject obj) { - assert (UseCompressedOops, "should only be used for compressed oops"); - assert (Universe::heap() != NULL, "java heap should be initialized"); - assert (oop_recorder() != NULL, "this assembler needs an OopRecorder"); - +#ifdef ASSERT + { + ThreadInVMfromNative tiv(JavaThread::current()); + assert (UseCompressedOops, "should only be used for compressed oops"); + assert (Universe::heap() != NULL, "java heap should be initialized"); + assert (oop_recorder() != NULL, "this assembler needs an OopRecorder"); + assert(Universe::heap()->is_in_reserved(JNIHandles::resolve(obj)), "should be real oop"); + } +#endif int oop_index = oop_recorder()->find_index(obj); - assert(Universe::heap()->is_in_reserved(JNIHandles::resolve(obj)), "should be real oop"); - InstructionMark im(this); RelocationHolder rspec = oop_Relocation::spec(oop_index); code_section()->relocate(inst_mark(), rspec); @@ -4006,8 +4009,13 @@ if (obj == NULL) { oop_index = oop_recorder()->allocate_oop_index(obj); } else { +#ifdef ASSERT + { + ThreadInVMfromNative tiv(JavaThread::current()); + assert(Universe::heap()->is_in_reserved(JNIHandles::resolve(obj)), "should be real oop"); + } +#endif oop_index = oop_recorder()->find_index(obj); - assert(Universe::heap()->is_in_reserved(JNIHandles::resolve(obj)), "should be real oop"); } RelocationHolder rspec = oop_Relocation::spec(oop_index); if (! immediate) { @@ -4030,8 +4038,13 @@ } Address MacroAssembler::constant_oop_address(jobject obj) { - assert(oop_recorder() != NULL, "this assembler needs an OopRecorder"); - assert(Universe::heap()->is_in_reserved(JNIHandles::resolve(obj)), "not an oop"); +#ifdef ASSERT + { + ThreadInVMfromNative tiv(JavaThread::current()); + assert(oop_recorder() != NULL, "this assembler needs an OopRecorder"); + assert(Universe::heap()->is_in_reserved(JNIHandles::resolve(obj)), "not an oop"); + } +#endif int oop_index = oop_recorder()->find_index(obj); return Address((address)obj, oop_Relocation::spec(oop_index)); }
20-12-2017
This issue looks like the same problem as JDK-8191227 and should be fixed similarly.
19-12-2017
Hi [~hseigel], Can this aarch64 build failure reported after JDK-8167372, missed during validations?
19-12-2017
hs_err file from the build.
18-12-2017