From aph at redhat.com Fri Jan 3 04:53:57 2014 From: aph at redhat.com (Andrew Haley) Date: Fri, 03 Jan 2014 12:53:57 +0000 Subject: [aarch64-port-dev ] Very large code caches Message-ID: <52C6B2E5.9010400@redhat.com> The AArch64 immediate call instructions span +/- 128 Mbytes. This is a good match for us: the default ReservedCodeCacheSize is 48M, and it takes a lot to fill 128M. Nonetheless, is is possible. I can envisage a multi-tenant system that generates huge amounts of code, for example. So, the question for us is: what should we do? I've been kicking around a solution, attached here. We can have a long call instruction, and for the sake of the exercise I've been trying lea(r16, dest); blr(r16) . The back end has to be changed in quite a few places, but the real problem is that the resulting call site is not MT-safe: it can't be patched atomically. To make that work we'd have to move the destination address into the constant pool. So, I'm envisaging a solution where we wait until, when patching, we have the first branch out of range. We then patch the site with a trap that calls deoptimize. We also set a flag in the assembler. When the method is recompiled after deoptimization it'll have long branches, and from that time onwards all (inter-method) branches will be long. A gnarly problem is nmethod::make_not_entrant_or_zombie(). At present we place a single NOP at the entry point of every method, and when we deoptimize it we patch it with a branch to handle_wrong_method. We can do this iff handle_wrong_method is reachable, i.e. less than 128Mbytes away. We could deposit a copy of the handle_wrong_method stub every 128Mbytes or so, but a better plan is to replace our NOP with a trap of some kind. DCPS1 generates an illegal instruction trap, so I've used that. It seems to work. None of this is very nice, but it all works. It shouldn't affect anything significant in most cases because our branch overflow will never happen, and we'll not do anything different. Thoughts? Andrew. -------------- next part -------------- diff -r 970ff006b665 src/cpu/aarch64/vm/aarch64.ad --- a/src/cpu/aarch64/vm/aarch64.ad Tue Dec 31 12:48:20 2013 +0000 +++ b/src/cpu/aarch64/vm/aarch64.ad Fri Jan 03 12:50:14 2014 +0000 @@ -749,7 +749,7 @@ // call should be a simple bl // unless this is a method handle invoke in which case it is // mov(rfp, sp), bl, mov(sp, rfp) - int off = 4; + int off = MacroAssembler::ret_addr_offset(); if (_method_handle_invoke) { off += 4; } @@ -766,7 +766,7 @@ // or // adrp // if !NearCPool // ldr - int off = 8; + int off = MacroAssembler::ret_addr_offset() + 4; if (!NearCpool) { off += 4; } @@ -781,7 +781,7 @@ // blrt rscratch1 CodeBlob *cb = CodeCache::find_blob(_entry_point); if (cb) { - return 4; + return MacroAssembler::ret_addr_offset(); } else { return 20; } @@ -1434,7 +1434,8 @@ // TODO // can we avoid this skip and still use a reloc? __ br(Assembler::EQ, skip); - __ b(RuntimeAddress(SharedRuntime::get_ic_miss_stub())); + __ lea(rscratch1, RuntimeAddress(SharedRuntime::get_ic_miss_stub())); + __ br(rscratch1); __ bind(skip); } @@ -1465,7 +1466,8 @@ __ start_a_stub(size_exception_handler()); if (base == NULL) return 0; // CodeBuffer::expand failed int offset = __ offset(); - __ b(RuntimeAddress(OptoRuntime::exception_blob()->entry_point())); + __ lea(rscratch1, RuntimeAddress(OptoRuntime::exception_blob()->entry_point())); + __ br(rscratch1); assert(__ offset() - offset <= (int) size_exception_handler(), "overflow"); __ end_a_stub(); return offset; @@ -1473,8 +1475,8 @@ uint size_deopt_handler() { - // count one adr and one branch instruction - return 2 * NativeInstruction::instruction_size; + // count one adr, one lea, and one branch instruction + return 6 * NativeInstruction::instruction_size; } // Emit deopt handler code. @@ -1489,8 +1491,8 @@ int offset = __ offset(); __ adr(lr, __ pc()); - // should we load this into rscratch1 and use a br? - __ b(RuntimeAddress(SharedRuntime::deopt_blob()->unpack())); + __ lea(rscratch1, RuntimeAddress(SharedRuntime::deopt_blob()->unpack())); + __ br(rscratch1); assert(__ offset() - offset <= (int) size_deopt_handler(), "overflow"); __ end_a_stub(); @@ -2880,6 +2882,13 @@ // Emit stub for static call CompiledStaticCall::emit_to_interp_stub(cbuf, mark); } + { + Label over; + __ b(over); + for (int i = 0; i < 512; i++) + __ nop(); + __ bind(over); + } %} enc_class aarch64_enc_java_handle_call(method meth) %{ @@ -2952,12 +2961,15 @@ enc_class aarch64_enc_rethrow() %{ MacroAssembler _masm(&cbuf); - __ b(RuntimeAddress(OptoRuntime::rethrow_stub())); + __ lea(rscratch1, RuntimeAddress(OptoRuntime::rethrow_stub())); + __ br(rscratch1); %} enc_class aarch64_enc_ret() %{ MacroAssembler _masm(&cbuf); __ ret(lr); + for (int i = 0; i < 512; i++) + __ nop(); %} enc_class aarch64_enc_tail_call(iRegP jump_target) %{ diff -r 970ff006b665 src/cpu/aarch64/vm/assembler_aarch64.hpp --- a/src/cpu/aarch64/vm/assembler_aarch64.hpp Tue Dec 31 12:48:20 2013 +0000 +++ b/src/cpu/aarch64/vm/assembler_aarch64.hpp Fri Jan 03 12:50:14 2014 +0000 @@ -116,7 +116,7 @@ // current method -- must be in a call-clobbered register REGISTER_DECLARATION(Register, rmethod, r12); -// non-volatile (callee-save) registers are r16-29 +// non-volatile (callee-save) registers are r19-29 // of which the following are dedicated global state // link register diff -r 970ff006b665 src/cpu/aarch64/vm/icBuffer_aarch64.cpp --- a/src/cpu/aarch64/vm/icBuffer_aarch64.cpp Tue Dec 31 12:48:20 2013 +0000 +++ b/src/cpu/aarch64/vm/icBuffer_aarch64.cpp Fri Jan 03 12:50:14 2014 +0000 @@ -36,7 +36,7 @@ #include "oops/oop.inline2.hpp" int InlineCacheBuffer::ic_stub_code_size() { - return NativeInstruction::instruction_size * 5; + return 4 * 7; } @@ -50,25 +50,27 @@ // (2) these ICStubs are removed *before* a GC happens, so the roots disappear // assert(cached_value == NULL || cached_oop->is_perm(), "must be perm oop"); - Label l; - masm->ldr(rscratch2, l); - masm->b(ExternalAddress(entry_point)); - masm->bind(l); + Label l1, l2; + masm->ldr(rscratch2, l1); + masm->ldr(r19, l2); + masm->br(r19); + masm->bind(l1); masm->emit_int64((int64_t)cached_value); + masm->bind(l2); + masm->emit_int64((int64_t)entry_point); // Only need to invalidate the 1st two instructions - not the whole ic stub - ICache::invalidate_range(code_begin, NativeInstruction::instruction_size * 2); + ICache::invalidate_range(code_begin, NativeInstruction::instruction_size * 3); } address InlineCacheBuffer::ic_buffer_entry_point(address code_begin) { - NativeMovConstReg* move = nativeMovConstReg_at(code_begin); // creation also verifies the object - NativeJump* jump = nativeJump_at(code_begin + 4); - return jump->jump_destination(); + NativeMovConstReg* move = nativeMovConstReg_at(code_begin + 4); // creation also verifies the object + return (address)move->data(); } void* InlineCacheBuffer::ic_buffer_cached_value(address code_begin) { // creation also verifies the object - uintptr_t *p = (uintptr_t *)(code_begin + 8); + uintptr_t *p = (uintptr_t *)(code_begin + 12); void* o = (void*)*p; return o; } diff -r 970ff006b665 src/cpu/aarch64/vm/macroAssembler_aarch64.cpp --- a/src/cpu/aarch64/vm/macroAssembler_aarch64.cpp Tue Dec 31 12:48:20 2013 +0000 +++ b/src/cpu/aarch64/vm/macroAssembler_aarch64.cpp Fri Jan 03 12:50:14 2014 +0000 @@ -63,6 +63,8 @@ #define BIND(label) bind(label); BLOCK_COMMENT(#label ":") +bool MacroAssembler::_far_branches; + void MacroAssembler::pd_patch_instruction(address branch, address target) { long offset = (target - branch) >> 2; unsigned insn = *(unsigned*)branch; diff -r 970ff006b665 src/cpu/aarch64/vm/macroAssembler_aarch64.hpp --- a/src/cpu/aarch64/vm/macroAssembler_aarch64.hpp Tue Dec 31 12:48:20 2013 +0000 +++ b/src/cpu/aarch64/vm/macroAssembler_aarch64.hpp Fri Jan 03 12:50:14 2014 +0000 @@ -28,6 +28,7 @@ #define CPU_AARCH64_VM_MACROASSEMBLER_AARCH64_HPP #include "asm/assembler.hpp" +#include "code/codeCache.hpp" // MacroAssembler extends Assembler by frequently used macros. // @@ -89,8 +90,8 @@ void call_VM_helper(Register oop_result, address entry_point, int number_of_arguments, bool check_exceptions = true); - // Maximum size of class area in Metaspace when compressed - uint64_t use_XOR_for_compressed_class_base; + bool use_XOR_for_compressed_class_base; + static bool _far_branches; public: MacroAssembler(CodeBuffer* code) : Assembler(code) { @@ -99,6 +100,14 @@ (uint64_t)Universe::narrow_klass_base()) && ((uint64_t)Universe::narrow_klass_base() > (1u << log2_intptr(CompressedClassSpaceSize)))); + _far_branches = ReservedCodeCacheSize > 6*1024*1024; + } + + static int ret_addr_offset() { + if (_far_branches) + return 5 * sizeof (uint32_t); + else + return sizeof (uint32_t); } // Biased locking support @@ -195,6 +204,31 @@ } } +// Redefine branch instructions to use far variants. r16 is used here +// because it's reserved for this purpose by the system ABI. +#define BRANCH(INSN) \ + void INSN(const Address &dest) { \ + if (_far_branches) { \ + lea(r16, dest); \ + INSN##r(r16); \ + } else { \ + InstructionMark im(this); \ + code_section()->relocate(inst_mark(), dest.rspec()); \ + Assembler::INSN(dest.target()); \ + } \ + } \ + void INSN(Label &l) { \ + Assembler::INSN(l); \ + } \ + void INSN(address a) { \ + Assembler::INSN(a); \ + } + +BRANCH(bl) +BRANCH(b) + +#undef BRANCH + inline void moviw(Register Rd, unsigned imm) { orrw(Rd, zr, imm); } inline void movi(Register Rd, unsigned imm) { orr(Rd, zr, imm); } diff -r 970ff006b665 src/cpu/aarch64/vm/nativeInst_aarch64.cpp --- a/src/cpu/aarch64/vm/nativeInst_aarch64.cpp Tue Dec 31 12:48:20 2013 +0000 +++ b/src/cpu/aarch64/vm/nativeInst_aarch64.cpp Fri Jan 03 12:50:14 2014 +0000 @@ -45,7 +45,11 @@ void NativeCall::verify() { ; } address NativeCall::destination() const { - return instruction_address() + displacement(); + return MacroAssembler::target_addr_for_insn(instruction_address(), int_at(instruction_offset)); +} + +void NativeCall::set_destination(address dest) { + MacroAssembler::pd_patch_instruction(instruction_address(), dest); } void NativeCall::print() { Unimplemented(); } @@ -208,17 +212,16 @@ } // MT safe inserting of a jump over an unknown instruction sequence (used by nmethod::makeZombie) +// The problem: jump_to may be an N-word instruction. +// Atomic write can be only with 1 word. void NativeJump::patch_verified_entry(address entry, address verified_entry, address dest) { - ptrdiff_t disp = dest - verified_entry; - guarantee(disp < 1 << 27 && disp > - (1 << 27), "branch overflow"); - - unsigned int insn = (0b000101 << 26) | ((disp >> 2) & 0x3ffffff); - - assert(nativeInstruction_at(verified_entry)->is_jump_or_nop(), - "Aarch64 cannot replace non-jump with jump"); - *(unsigned int*)verified_entry = insn; - ICache::invalidate_range(verified_entry, instruction_size); + ResourceMark rm; + int code_size = 1 * 4; + CodeBuffer cb(verified_entry, code_size + 1); + MacroAssembler* a = new MacroAssembler(&cb); + a->dpcs1(0); // "dpcs1" must agree with code in the signal handler + ICache::invalidate_range(verified_entry, code_size); } diff -r 970ff006b665 src/cpu/aarch64/vm/nativeInst_aarch64.hpp --- a/src/cpu/aarch64/vm/nativeInst_aarch64.hpp Tue Dec 31 12:48:20 2013 +0000 +++ b/src/cpu/aarch64/vm/nativeInst_aarch64.hpp Fri Jan 03 12:50:14 2014 +0000 @@ -102,6 +102,10 @@ static bool maybe_cpool_ref(address instr) { return is_adrp_at(instr) || is_ldr_literal_at(instr); } + + bool is_zombie() { + return int_at(0) == (int)0xd4a00001; // DCPS1 + } }; inline NativeInstruction* nativeInstruction_at(address address) { @@ -113,8 +117,9 @@ } inline NativeCall* nativeCall_at(address address); -// The NativeCall is an abstraction for accessing/manipulating native call imm32/rel32off -// instructions (used to manipulate inline caches, primitive & dll calls, etc.). +// The NativeCall is an abstraction for accessing/manipulating native +// call instructions (used to manipulate inline caches, primitive & +// DSO calls, etc.). class NativeCall: public NativeInstruction { public: @@ -122,25 +127,24 @@ instruction_size = 4, instruction_offset = 0, displacement_offset = 0, - return_address_offset = 4 + bl_address_offset = 4 }; enum { cache_line_size = BytesPerWord }; // conservative estimate! + int return_address_offset() const { + uint32_t insn = *(uint32_t*)instruction_address(); + if ((insn >> 26) == 0b100101) // BL (offset) + return bl_address_offset; + else // 4 mov# insns; blr + return bl_address_offset + 4 * sizeof (uint32_t); + } address instruction_address() const { return addr_at(instruction_offset); } - address next_instruction_address() const { return addr_at(return_address_offset); } + address next_instruction_address() const { return addr_at(return_address_offset()); } int displacement() const { return (int_at(displacement_offset) << 6) >> 4; } address displacement_address() const { return addr_at(displacement_offset); } - address return_address() const { return addr_at(return_address_offset); } + address return_address() const { return addr_at(return_address_offset()); } address destination() const; - void set_destination(address dest) { - int offset = dest - instruction_address(); - unsigned int insn = 0b100101 << 26; - assert((offset & 3) == 0, "should be"); - offset >>= 2; - offset &= (1 << 26) - 1; // mask off insn part - insn |= offset; - set_int_at(displacement_offset, insn); - } + void set_destination(address dest); // Similar to replace_mt_safe, but just changes the destination. The // important thing is that free-running threads are able to execute @@ -169,7 +173,7 @@ } static bool is_call_before(address return_address) { - return is_call_at(return_address - NativeCall::return_address_offset); + return is_call_at(return_address - NativeCall::bl_address_offset); } static bool is_call_to(address instr, address target) { @@ -192,15 +196,16 @@ } inline NativeCall* nativeCall_before(address return_address) { - NativeCall* call = (NativeCall*)(return_address - NativeCall::return_address_offset); + NativeCall* call = (NativeCall*)(return_address - NativeCall::bl_address_offset); + call = (NativeCall*)(return_address - call->return_address_offset()); #ifdef ASSERT call->verify(); #endif return call; } -// An interface for accessing/manipulating native mov reg, imm32 instructions. -// (used to manipulate inlined 32bit data dll calls, etc.) +// An interface for accessing/manipulating native 64-bit movk/movz +// reg, imm instructions. class NativeMovConstReg: public NativeInstruction { public: enum Aarch64_specific_constants { @@ -260,21 +265,10 @@ } }; -// An interface for accessing/manipulating native moves of the form: -// mov[b/w/l/q] [reg + offset], reg (instruction_code_reg2mem) -// mov[b/w/l/q] reg, [reg+offset] (instruction_code_mem2reg -// mov[s/z]x[w/b/q] [reg + offset], reg -// fld_s [reg+offset] -// fld_d [reg+offset] -// fstp_s [reg + offset] -// fstp_d [reg + offset] -// mov_literal64 scratch, ; mov[b/w/l/q] 0(scratch),reg | mov[b/w/l/q] reg,0(scratch) -// + // Warning: These routines must be able to handle any instruction sequences // that are generated as a result of the load/store byte,word,long -// macros. For example: The load_unsigned_byte instruction generates -// an xor reg,reg inst prior to generating the movb instruction. This -// class must skip the xor instruction. +// macros. class NativeMovRegMem: public NativeInstruction { enum AArch64_specific_constants { diff -r 970ff006b665 src/cpu/aarch64/vm/sharedRuntime_aarch64.cpp --- a/src/cpu/aarch64/vm/sharedRuntime_aarch64.cpp Tue Dec 31 12:48:20 2013 +0000 +++ b/src/cpu/aarch64/vm/sharedRuntime_aarch64.cpp Fri Jan 03 12:50:14 2014 +0000 @@ -739,7 +739,6 @@ __ ldr(rmethod, Address(holder, CompiledICHolder::holder_method_offset())); __ br(Assembler::EQ, ok); __ b(RuntimeAddress(SharedRuntime::get_ic_miss_stub())); - __ bind(ok); // Method might have been compiled since the call site was patched to // interpreted; if that is the case treat it as a miss so we can get diff -r 970ff006b665 src/os_cpu/linux_aarch64/vm/os_linux_aarch64.cpp --- a/src/os_cpu/linux_aarch64/vm/os_linux_aarch64.cpp Tue Dec 31 12:48:20 2013 +0000 +++ b/src/os_cpu/linux_aarch64/vm/os_linux_aarch64.cpp Fri Jan 03 12:50:14 2014 +0000 @@ -211,6 +211,16 @@ extern "C" void FetchNResume () ; #endif +inline static bool checkZombie(ucontext_t* uc, address* pc, address* stub) { + if (nativeInstruction_at(*pc)->is_zombie()) { + // zombie method (dpcs1 instruction) + *stub = SharedRuntime::get_handle_wrong_method_stub(); + + return true; + } + return false; +} + extern "C" JNIEXPORT int JVM_handle_linux_signal(int sig, siginfo_t* info, @@ -408,6 +418,9 @@ } } + if (sig == SIGILL) + checkZombie(uc, &pc, &stub); + if (stub != NULL) { // save all thread context in case we need to restore it if (thread != NULL) thread->set_saved_exception_pc(pc); From edward.nevill at linaro.org Tue Jan 7 02:47:47 2014 From: edward.nevill at linaro.org (Edward Nevill) Date: Tue, 07 Jan 2014 10:47:47 +0000 Subject: [aarch64-port-dev ] Very large code caches In-Reply-To: <52C6B2E5.9010400@redhat.com> References: <52C6B2E5.9010400@redhat.com> Message-ID: <1389091667.24108.85.camel@localhost.localdomain> On Fri, 2014-01-03 at 12:53 +0000, Andrew Haley wrote: > The AArch64 immediate call instructions span +/- 128 Mbytes. This is > a good match for us: the default ReservedCodeCacheSize is 48M, and it > takes a lot to fill 128M. With tiered compilation the code cache size is set to 5 * ReservedCodeCacheSize. So we can currently have a code cache size of 240M. > I've been kicking around a solution, attached here. We can have a > long call instruction, and for the sake of the exercise I've been > trying lea(r16, dest); blr(r16) . dest is a literal here so this ends up being mov x0, .. / movk x0, .. / movk x0, .. / movk x0, .. can we use adrp / add instead for 2 instructions instead of 4? This allows a code cache size of up to 4G (the max allowed in hotspot is 2G in any case). > The back end has to be changed in > quite a few places, but the real problem is that the resulting call > site is not MT-safe: it can't be patched atomically. To make that > work we'd have to move the destination address into the constant pool. > > So, I'm envisaging a solution where we wait until, when patching, we > have the first branch out of range. We then patch the site with a > trap that calls deoptimize. We also set a flag in the assembler. When > the method is recompiled after deoptimization it'll have long > branches, and from that time onwards all (inter-method) branches will > be long. Apologies if I have misunderstood but... After the 1st out of range patchup all branches are compiled as long branches. Does this include branches which subsequently need patching. In which case this will again be non MT safe. > > A gnarly problem is nmethod::make_not_entrant_or_zombie(). At present > we place a single NOP at the entry point of every method, and when we > deoptimize it we patch it with a branch to handle_wrong_method. We > can do this iff handle_wrong_method is reachable, i.e. less than > 128Mbytes away. We could deposit a copy of the handle_wrong_method > stub every 128Mbytes or so, but a better plan is to replace our NOP > with a trap of some kind. DCPS1 generates an illegal instruction > trap, so I've used that. It seems to work. > > None of this is very nice, but it all works. It shouldn't affect > anything significant in most cases because our branch overflow will > never happen, and we'll not do anything different. As you say it is not very nice, but it doesn't happen very often. I assume the code you attached is experimental and will be tidied up before being pushed. There seems to be a lot of debug code / magic constants. All the best, Ed. From aph at redhat.com Tue Jan 7 03:03:03 2014 From: aph at redhat.com (Andrew Haley) Date: Tue, 07 Jan 2014 11:03:03 +0000 Subject: [aarch64-port-dev ] Very large code caches In-Reply-To: <1389091667.24108.85.camel@localhost.localdomain> References: <52C6B2E5.9010400@redhat.com> <1389091667.24108.85.camel@localhost.localdomain> Message-ID: <52CBDEE7.8070109@redhat.com> On 01/07/2014 10:47 AM, Edward Nevill wrote: > On Fri, 2014-01-03 at 12:53 +0000, Andrew Haley wrote: >> The AArch64 immediate call instructions span +/- 128 Mbytes. This is >> a good match for us: the default ReservedCodeCacheSize is 48M, and it >> takes a lot to fill 128M. > > With tiered compilation the code cache size is set to 5 * > ReservedCodeCacheSize. So we can currently have a code cache size of > 240M. > >> I've been kicking around a solution, attached here. We can have a >> long call instruction, and for the sake of the exercise I've been >> trying lea(r16, dest); blr(r16) . > > dest is a literal here so this ends up being > > mov x0, .. / movk x0, .. / movk x0, .. / movk x0, .. > > can we use adrp / add instead for 2 instructions instead of 4? This > allows a code cache size of up to 4G (the max allowed in hotspot is 2G > in any case). I don't think so, because we can't update it atomically. I think we have to use the constant pool. >> The back end has to be changed in >> quite a few places, but the real problem is that the resulting call >> site is not MT-safe: it can't be patched atomically. To make that >> work we'd have to move the destination address into the constant pool. >> >> So, I'm envisaging a solution where we wait until, when patching, we >> have the first branch out of range. We then patch the site with a >> trap that calls deoptimize. We also set a flag in the assembler. When >> the method is recompiled after deoptimization it'll have long >> branches, and from that time onwards all (inter-method) branches will >> be long. > > Apologies if I have misunderstood but... > > After the 1st out of range patchup all branches are compiled as long > branches. Does this include branches which subsequently need patching. > In which case this will again be non MT safe. Not if we use the cpool. >> A gnarly problem is nmethod::make_not_entrant_or_zombie(). At present >> we place a single NOP at the entry point of every method, and when we >> deoptimize it we patch it with a branch to handle_wrong_method. We >> can do this iff handle_wrong_method is reachable, i.e. less than >> 128Mbytes away. We could deposit a copy of the handle_wrong_method >> stub every 128Mbytes or so, but a better plan is to replace our NOP >> with a trap of some kind. DCPS1 generates an illegal instruction >> trap, so I've used that. It seems to work. >> >> None of this is very nice, but it all works. It shouldn't affect >> anything significant in most cases because our branch overflow will >> never happen, and we'll not do anything different. > > As you say it is not very nice, but it doesn't happen very often. > > I assume the code you attached is experimental and will be tidied up > before being pushed. There seems to be a lot of debug code / magic > constants. Indeed. Andrew. From edward.nevill at linaro.org Wed Jan 8 03:18:39 2014 From: edward.nevill at linaro.org (Edward Nevill) Date: Wed, 08 Jan 2014 11:18:39 +0000 Subject: [aarch64-port-dev ] TestStackBangRbp hangs Message-ID: <1389179919.27478.20.camel@localhost.localdomain> Hi, The following test program causes openjdk to hang indefinitely requiring a kill -9 to stop the process. To replicate - compile the test program javac TestStackBangRbp.java - run it as follows java -Xcomp TestStackBangRbp Note that the problem occurs for both client and server and also occurs on both builtin sim and on the RTSM model. If you add java -Xcomp -XX:+PrintCompilation -XX:+TracePatching TestStackBangRbp the last few lines of the output look like 8291 368 b TestStackBangRbp:: (86 bytes) Deoptimizing because patch is needed 8302 368 TestStackBangRbp:: (86 bytes) made not entrant 8303 369 b TestStackBangRbp::main (38 bytes) 8341 370 b TestStackBangRbp::m1 (246 bytes) 8375 371 !b TestStackBangRbp::m2 (35 bytes) Deoptimizing because patch is needed 8463 371 ! TestStackBangRbp::m2 (35 bytes) made not entrant If I then add -XX:-DeoptimizeWhenPatching, IE java -Xcomp -XX:-DeoptimizeWhenPatching TestStackBangRbp The test passes. So it looks like a problem with stack overflow when deoptimizing (or having just deoptimized). Looks like fun:-). Ed. --- TestStackBangRbp.java --- /* * Copyright (c) 2013, Oracle and/or its affiliates. All rights reserved. * DO NOT ALTER OR REMOVE COPYRIGHT NOTICES OR THIS FILE HEADER. * * This code is free software; you can redistribute it and/or modify it * under the terms of the GNU General Public License version 2 only, as * published by the Free Software Foundation. * * This code is distributed in the hope that it will be useful, but WITHOUT * ANY WARRANTY; without even the implied warranty of MERCHANTABILITY or * FITNESS FOR A PARTICULAR PURPOSE. See the GNU General Public License * version 2 for more details (a copy is included in the LICENSE file that * accompanied this code). * * You should have received a copy of the GNU General Public License version * 2 along with this work; if not, write to the Free Software Foundation, * Inc., 51 Franklin St, Fifth Floor, Boston, MA 02110-1301 USA. * * Please contact Oracle, 500 Oracle Parkway, Redwood Shores, CA 94065 USA * or visit www.oracle.com if you need additional information or have any * questions. */ /* * @test * @bug 8028308 * @summary rbp not restored when stack overflow is thrown from deopt/uncommon trap blobs * @run main/othervm -XX:-BackgroundCompilation -XX:CompileCommand=dontinline,TestStackBangRbp::m1 -XX:CompileCommand=exclude,TestStackBangRbp::m2 -Xss256K -XX:-UseOnStackReplacement TestStackBangRbp * */ public class TestStackBangRbp { static class UnloadedClass1 { } static class UnloadedClass2 { } static Object m1(boolean deopt) { long l0, l1, l2, l3, l4, l5, l6, l7, l8, l9, l10, l11, l12, l13, l14, l15, l16, l17, l18, l19, l20, l21, l22, l23, l24, l25, l26, l27, l28, l29, l30, l31, l32, l33, l34, l35, l36, l37, l38, l39, l40, l41, l42, l43, l44, l45, l46, l47, l48, l49, l50, l51, l52, l53, l54, l55, l56, l57, l58, l59, l60, l61, l62, l63, l64, l65, l66, l67, l68, l69, l70, l71, l72, l73, l74, l75, l76, l77, l78, l79, l80, l81, l82, l83, l84, l85, l86, l87, l88, l89, l90, l91, l92, l93, l94, l95, l96, l97, l98, l99, l100, l101, l102, l103, l104, l105, l106, l107, l108, l109, l110, l111, l112, l113, l114, l115, l116, l117, l118, l119, l120, l121, l122, l123, l124, l125, l126, l127, l128, l129, l130, l131, l132, l133, l134, l135, l136, l137, l138, l139, l140, l141, l142, l143, l144, l145, l146, l147, l148, l149, l150, l151, l152, l153, l154, l155, l156, l157, l158, l159, l160, l161, l162, l163, l164, l165, l166, l167, l168, l169, l170, l171, l172, l173, l174, l175, l176, l177, l178, l179, l180, l181, l182, l183, l184, l185, l186, l187, l188, l189, l190, l191, l192, l193, l194, l195, l196, l197, l198, l199, l200, l201, l202, l203, l204, l205, l206, l207, l208, l209, l210, l211, l212, l213, l214, l215, l216, l217, l218, l219, l220, l221, l222, l223, l224, l225, l226, l227, l228, l229, l230, l231, l232, l233, l234, l235, l236, l237, l238, l239, l240, l241, l242, l243, l244, l245, l246, l247, l248, l249, l250, l251, l252, l253, l254, l255, l256, l257, l258, l259, l260, l261, l262, l263, l264, l265, l266, l267, l268, l269, l270, l271, l272, l273, l274, l275, l276, l277, l278, l279, l280, l281, l282, l283, l284, l285, l286, l287, l288, l289, l290, l291, l292, l293, l294, l295, l296, l297, l298, l299, l300, l301, l302, l303, l304, l305, l306, l307, l308, l309, l310, l311, l312, l313, l314, l315, l316, l317, l318, l319, l320, l321, l322, l323, l324, l325, l326, l327, l328, l329, l330, l331, l332, l333, l334, l335, l336, l337, l338, l339, l340, l341, l342, l343, l344, l345, l346, l347, l348, l349, l350, l351, l352, l353, l354, l355, l356, l357, l358, l359, l360, l361, l362, l363, l364, l365, l366, l367, l368, l369, l370, l371, l372, l373, l374, l375, l376, l377, l378, l379, l380, l381, l382, l383, l384, l385, l386, l387, l388, l389, l390, l391, l392, l393, l394, l395, l396, l397, l398, l399, l400, l401, l402, l403, l404, l405, l406, l407, l408, l409, l410, l411, l412, l413, l414, l415, l416, l417, l418, l419, l420, l421, l422, l423, l424, l425, l426, l427, l428, l429, l430, l431, l432, l433, l434, l435, l436, l437, l438, l439, l440, l441, l442, l443, l444, l445, l446, l447, l448, l449, l450, l451, l452, l453, l454, l455, l456, l457, l458, l459, l460, l461, l462, l463, l464, l465, l466, l467, l468, l469, l470, l471, l472, l473, l474, l475, l476, l477, l478, l479, l480, l481, l482, l483, l484, l485, l486, l487, l488, l489, l490, l491, l492, l493, l494, l495, l496, l497, l498, l499, l500, l501, l502, l503, l504, l505, l506, l507, l508, l509, l510, l511; long ll0, ll1, ll2, ll3, ll4, ll5, ll6, ll7, ll8, ll9, ll10, ll11, ll12, ll13, ll14, ll15, ll16, ll17, ll18, ll19, ll20, ll21, ll22, ll23, ll24, ll25, ll26, ll27, ll28, ll29, ll30, ll31, ll32, ll33, ll34, ll35, ll36, ll37, ll38, ll39, ll40, ll41, ll42, ll43, ll44, ll45, ll46, ll47, ll48, ll49, ll50, ll51, ll52, ll53, ll54, ll55, ll56, ll57, ll58, ll59, ll60, ll61, ll62, ll63, ll64, ll65, ll66, ll67, ll68, ll69, ll70, ll71, ll72, ll73, ll74, ll75, ll76, ll77, ll78, ll79, ll80, ll81, ll82, ll83, ll84, ll85, ll86, ll87, ll88, ll89, ll90, ll91, ll92, ll93, ll94, ll95, ll96, ll97, ll98, ll99, ll100, ll101, ll102, ll103, ll104, ll105, ll106, ll107, ll108, ll109, ll110, ll111, ll112, ll113, ll114, ll115, ll116, ll117, ll118, ll119, ll120, ll121, ll122, ll123, ll124, ll125, ll126, ll127, ll128, ll129, ll130, ll131, ll132, ll133, ll134, ll135, ll136, ll137, ll138, ll139, ll140, ll141, ll142, ll143, ll144, ll145, ll146, ll147, ll148, ll149, ll150, ll151, ll152, ll153, ll154, ll155, ll156, ll157, ll158, ll159, ll160, ll161, ll162, ll163, ll164, ll165, ll166, ll167, ll168, ll169, ll170, ll171, ll172, ll173, ll174, ll175, ll176, ll177, ll178, ll179, ll180, ll181, ll182, ll183, ll184, ll185, ll186, ll187, ll188, ll189, ll190, ll191, ll192, ll193, ll194, ll195, ll196, ll197, ll198, ll199, ll200, ll201, ll202, ll203, ll204, ll205, ll206, ll207, ll208, ll209, ll210, ll211, ll212, ll213, ll214, ll215, ll216, ll217, ll218, ll219, ll220, ll221, ll222, ll223, ll224, ll225, ll226, ll227, ll228, ll229, ll230, ll231, ll232, ll233, ll234, ll235, ll236, ll237, ll238, ll239, ll240, ll241, ll242, ll243, ll244, ll245, ll246, ll247, ll248, ll249, ll250, ll251, ll252, ll253, ll254, ll255, ll256, ll257, ll258, ll259, ll260, ll261, ll262, ll263, ll264, ll265, ll266, ll267, ll268, ll269, ll270, ll271, ll272, ll273, ll274, ll275, ll276, ll277, ll278, ll279, ll280, ll281, ll282, ll283, ll284, ll285, ll286, ll287, ll288, ll289, ll290, ll291, ll292, ll293, ll294, ll295, ll296, ll297, ll298, ll299, ll300, ll301, ll302, ll303, ll304, ll305, ll306, ll307, ll308, ll309, ll310, ll311, ll312, ll313, ll314, ll315, ll316, ll317, ll318, ll319, ll320, ll321, ll322, ll323, ll324, ll325, ll326, ll327, ll328, ll329, ll330, ll331, ll332, ll333, ll334, ll335, ll336, ll337, ll338, ll339, ll340, ll341, ll342, ll343, ll344, ll345, ll346, ll347, ll348, ll349, ll350, ll351, ll352, ll353, ll354, ll355, ll356, ll357, ll358, ll359, ll360, ll361, ll362, ll363, ll364, ll365, ll366, ll367, ll368, ll369, ll370, ll371, ll372, ll373, ll374, ll375, ll376, ll377, ll378, ll379, ll380, ll381, ll382, ll383, ll384, ll385, ll386, ll387, ll388, ll389, ll390, ll391, ll392, ll393, ll394, ll395, ll396, ll397, ll398, ll399, ll400, ll401, ll402, ll403, ll404, ll405, ll406, ll407, ll408, ll409, ll410, ll411, ll412, ll413, ll414, ll415, ll416, ll417, ll418, ll419, ll420, ll421, ll422, ll423, ll424, ll425, ll426, ll427, ll428, ll429, ll430, ll431, ll432, ll433, ll434, ll435, ll436, ll437, ll438, ll439, ll440, ll441, ll442, ll443, ll444, ll445, ll446, ll447, ll448, ll449, ll450, ll451, ll452, ll453, ll454, ll455, ll456, ll457, ll458, ll459, ll460, ll461, ll462, ll463, ll464, ll465, ll466, ll467, ll468, ll469, ll470, ll471, ll472, ll473, ll474, ll475, ll476, ll477, ll478, ll479, ll480, ll481, ll482, ll483, ll484, ll485, ll486, ll487, ll488, ll489, ll490, ll491, ll492, ll493, ll494, ll495, ll496, ll497, ll498, ll499, ll500, ll501, ll502, ll503, ll504, ll505, ll506, ll507, ll508, ll509, ll510, ll511; int i1 = TestStackBangRbp.i1; int i2 = TestStackBangRbp.i2; int i3 = TestStackBangRbp.i3; int i4 = TestStackBangRbp.i4; int i5 = TestStackBangRbp.i5; int i6 = TestStackBangRbp.i6; int i7 = TestStackBangRbp.i7; int i8 = TestStackBangRbp.i8; int i9 = TestStackBangRbp.i9; int i10 = TestStackBangRbp.i10; int i11 = TestStackBangRbp.i11; int i12 = TestStackBangRbp.i12; int i13 = TestStackBangRbp.i13; int i14 = TestStackBangRbp.i14; int i15 = TestStackBangRbp.i15; int i16 = TestStackBangRbp.i16; TestStackBangRbp.i1 = i1; TestStackBangRbp.i2 = i2; TestStackBangRbp.i3 = i3; TestStackBangRbp.i4 = i4; TestStackBangRbp.i5 = i5; TestStackBangRbp.i6 = i6; TestStackBangRbp.i7 = i7; TestStackBangRbp.i8 = i8; TestStackBangRbp.i9 = i9; TestStackBangRbp.i10 = i10; TestStackBangRbp.i11 = i11; TestStackBangRbp.i12 = i12; TestStackBangRbp.i13 = i13; TestStackBangRbp.i14 = i14; TestStackBangRbp.i15 = i15; TestStackBangRbp.i16 = i16; if (deopt) { // deoptimize with integer in rbp UnloadedClass1 res = new UnloadedClass1(); // forces deopt with c2 return res; } return null; } static boolean m2(boolean deopt) { // call m2 recursively until stack overflow. Then call m3 that // will call m1 and trigger and deopt in m1 while keeping a // lot of objects live in registers at the call to m1 long l0, l1, l2, l3, l4, l5, l6, l7, l8, l9, l10, l11, l12, l13, l14, l15, l16, l17, l18, l19, l20, l21, l22, l23, l24, l25, l26, l27, l28, l29, l30, l31, l32, l33, l34, l35, l36, l37, l38, l39, l40, l41, l42, l43, l44, l45, l46, l47, l48, l49, l50, l51, l52, l53, l54, l55, l56, l57, l58, l59, l60, l61, l62, l63, l64, l65, l66, l67, l68, l69, l70, l71, l72, l73, l74, l75, l76, l77, l78, l79, l80, l81, l82, l83, l84, l85, l86, l87, l88, l89, l90, l91, l92, l93, l94, l95, l96, l97, l98, l99, l100, l101, l102, l103, l104, l105, l106, l107, l108, l109, l110, l111, l112, l113, l114, l115, l116, l117, l118, l119, l120, l121, l122, l123, l124, l125, l126, l127, l128, l129, l130, l131, l132, l133, l134, l135, l136, l137, l138, l139, l140, l141, l142, l143, l144, l145, l146, l147, l148, l149, l150, l151, l152, l153, l154, l155, l156, l157, l158, l159, l160, l161, l162, l163, l164, l165, l166, l167, l168, l169, l170, l171, l172, l173, l174, l175, l176, l177, l178, l179, l180, l181, l182, l183, l184, l185, l186, l187, l188, l189, l190, l191, l192, l193, l194, l195, l196, l197, l198, l199, l200, l201, l202, l203, l204, l205, l206, l207, l208, l209, l210, l211, l212, l213, l214, l215, l216, l217, l218, l219, l220, l221, l222, l223, l224, l225, l226, l227, l228, l229, l230, l231, l232, l233, l234, l235, l236, l237, l238, l239, l240, l241, l242, l243, l244, l245, l246, l247, l248, l249, l250, l251, l252, l253, l254, l255, l256, l257, l258, l259, l260, l261, l262, l263, l264, l265, l266, l267, l268, l269, l270, l271, l272, l273, l274, l275, l276, l277, l278, l279, l280, l281, l282, l283, l284, l285, l286, l287, l288, l289, l290, l291, l292, l293, l294, l295, l296, l297, l298, l299, l300, l301, l302, l303, l304, l305, l306, l307, l308, l309, l310, l311, l312, l313, l314, l315, l316, l317, l318, l319, l320, l321, l322, l323, l324, l325, l326, l327, l328, l329, l330, l331, l332, l333, l334, l335, l336, l337, l338, l339, l340, l341, l342, l343, l344, l345, l346, l347, l348, l349, l350, l351, l352, l353, l354, l355, l356, l357, l358, l359, l360, l361, l362, l363, l364, l365, l366, l367, l368, l369, l370, l371, l372, l373, l374, l375, l376, l377, l378, l379, l380, l381, l382, l383, l384, l385, l386, l387, l388, l389, l390, l391, l392, l393, l394, l395, l396, l397, l398, l399, l400, l401, l402, l403, l404, l405, l406, l407, l408, l409, l410, l411, l412, l413, l414, l415, l416, l417, l418, l419, l420, l421, l422, l423, l424, l425, l426, l427, l428, l429, l430, l431, l432, l433, l434, l435, l436, l437, l438, l439, l440, l441, l442, l443, l444, l445, l446, l447, l448, l449, l450, l451, l452, l453, l454, l455, l456, l457, l458, l459, l460, l461, l462, l463, l464, l465, l466, l467, l468, l469, l470, l471, l472, l473, l474, l475, l476, l477, l478, l479, l480, l481, l482, l483, l484, l485, l486, l487, l488, l489, l490, l491, l492, l493, l494, l495, l496, l497, l498, l499, l500, l501, l502, l503, l504, l505, l506, l507, l508, l509, l510, l511; boolean do_m3 = false; try { do_m3 = m2(deopt); } catch (StackOverflowError e) { return true; } if (do_m3) { m3(deopt); } return false; } static volatile Object o1 = new Object(); static volatile int i1 = 1; static volatile int i2 = 2; static volatile int i3 = 3; static volatile int i4 = 4; static volatile int i5 = 5; static volatile int i6 = 6; static volatile int i7 = 7; static volatile int i8 = 8; static volatile int i9 = 9; static volatile int i10 = 10; static volatile int i11 = 11; static volatile int i12 = 12; static volatile int i13 = 13; static volatile int i14 = 14; static volatile int i15 = 15; static volatile int i16 = 16; static void m3(boolean deopt) { Object o1 = TestStackBangRbp.o1; TestStackBangRbp.o1 = o1; try { m1(deopt); } catch (StackOverflowError e) { // deoptimize again. rbp holds an integer. It should have an object. UnloadedClass2 res = new UnloadedClass2(); // forces deopt with c2 } TestStackBangRbp.o1 = o1; } static public void main(String[] args) { // get m1 & m3 compiled for (int i = 0; i < 20000; i++) { m1(false); m3(false); } m2(true); System.out.println("TEST PASSED"); } } --- CUT HERE --- From aph at redhat.com Wed Jan 8 03:59:24 2014 From: aph at redhat.com (Andrew Haley) Date: Wed, 08 Jan 2014 11:59:24 +0000 Subject: [aarch64-port-dev ] TestStackBangRbp hangs In-Reply-To: <1389179919.27478.20.camel@localhost.localdomain> References: <1389179919.27478.20.camel@localhost.localdomain> Message-ID: <52CD3D9C.9050208@redhat.com> On 01/08/2014 11:18 AM, Edward Nevill wrote: > If I then add -XX:-DeoptimizeWhenPatching, IE > > java -Xcomp -XX:-DeoptimizeWhenPatching TestStackBangRbp > > The test passes. > > So it looks like a problem with stack overflow when deoptimizing (or having just deoptimized). You didn't say what your configured target was; I guess C1. Andrew. From aph at redhat.com Wed Jan 8 04:03:38 2014 From: aph at redhat.com (Andrew Haley) Date: Wed, 08 Jan 2014 12:03:38 +0000 Subject: [aarch64-port-dev ] TestStackBangRbp hangs In-Reply-To: <52CD3D9C.9050208@redhat.com> References: <1389179919.27478.20.camel@localhost.localdomain> <52CD3D9C.9050208@redhat.com> Message-ID: <52CD3E9A.9000506@redhat.com> On 01/08/2014 11:59 AM, Andrew Haley wrote: > On 01/08/2014 11:18 AM, Edward Nevill wrote: >> > If I then add -XX:-DeoptimizeWhenPatching, IE >> > >> > java -Xcomp -XX:-DeoptimizeWhenPatching TestStackBangRbp >> > >> > The test passes. >> > >> > So it looks like a problem with stack overflow when deoptimizing (or having just deoptimized). > You didn't say what your configured target was; I guess C1. I can't reproduce this with client or server. You'll have to tell me more about how you built it. Andrew. From adinn at redhat.com Wed Jan 8 04:04:26 2014 From: adinn at redhat.com (Andrew Dinn) Date: Wed, 08 Jan 2014 12:04:26 +0000 Subject: [aarch64-port-dev ] TestStackBangRbp hangs In-Reply-To: <52CD3D9C.9050208@redhat.com> References: <1389179919.27478.20.camel@localhost.localdomain> <52CD3D9C.9050208@redhat.com> Message-ID: <52CD3ECA.40106@redhat.com> On 08/01/14 11:59, Andrew Haley wrote: > On 01/08/2014 11:18 AM, Edward Nevill wrote: >> If I then add -XX:-DeoptimizeWhenPatching, IE >> >> java -Xcomp -XX:-DeoptimizeWhenPatching TestStackBangRbp >> >> The test passes. >> >> So it looks like a problem with stack overflow when deoptimizing (or having just deoptimized). > > You didn't say what your configured target was; I guess C1. Perhaps not as the code includes a comment about forcing a deopt in C2 regards, Andrew Dinn ----------- From aph at redhat.com Wed Jan 8 04:09:00 2014 From: aph at redhat.com (Andrew Haley) Date: Wed, 08 Jan 2014 12:09:00 +0000 Subject: [aarch64-port-dev ] TestStackBangRbp hangs In-Reply-To: <52CD3ECA.40106@redhat.com> References: <1389179919.27478.20.camel@localhost.localdomain> <52CD3D9C.9050208@redhat.com> <52CD3ECA.40106@redhat.com> Message-ID: <52CD3FDC.70602@redhat.com> On 01/08/2014 12:04 PM, Andrew Dinn wrote: > > > On 08/01/14 11:59, Andrew Haley wrote: >> On 01/08/2014 11:18 AM, Edward Nevill wrote: >>> If I then add -XX:-DeoptimizeWhenPatching, IE >>> >>> java -Xcomp -XX:-DeoptimizeWhenPatching TestStackBangRbp >>> >>> The test passes. >>> >>> So it looks like a problem with stack overflow when deoptimizing (or having just deoptimized). >> >> You didn't say what your configured target was; I guess C1. > > Perhaps not as the code includes a comment about forcing a deopt in C2 Well, the OP says either; but both work for me. Andrew. From edward.nevill at linaro.org Wed Jan 8 04:12:09 2014 From: edward.nevill at linaro.org (Edward Nevill) Date: Wed, 08 Jan 2014 12:12:09 +0000 Subject: [aarch64-port-dev ] TestStackBangRbp hangs In-Reply-To: <52CD3D9C.9050208@redhat.com> References: <1389179919.27478.20.camel@localhost.localdomain> <52CD3D9C.9050208@redhat.com> Message-ID: <1389183129.27478.25.camel@localhost.localdomain> On Wed, 2014-01-08 at 11:59 +0000, Andrew Haley wrote: > On 01/08/2014 11:18 AM, Edward Nevill wrote: > > If I then add -XX:-DeoptimizeWhenPatching, IE > > > > java -Xcomp -XX:-DeoptimizeWhenPatching TestStackBangRbp > > > > The test passes. > > > > So it looks like a problem with stack overflow when deoptimizing (or having just deoptimized). > > You didn't say what your configured target was; I guess C1. Sorry. I should probably make a habit of always including the output of java -version It happens with both C1 and C2 Here is the output of java -version for C1 and C2 respectively ~/tmp$ /home/ed/images/j2sdk-client-fastdebug/bin/java -version openjdk version "1.8.0-internal-fastdebug" OpenJDK Runtime Environment (build 1.8.0-internal-fastdebug-ed_2014_01_07_15_36-b00) OpenJDK 64-Bit Client VM (build 25.0-b59-fastdebug, mixed mode) ~/tmp$ /home/ed/images/j2sdk-server-fastdebug/bin/java -version openjdk version "1.8.0-internal-fastdebug" OpenJDK Runtime Environment (build 1.8.0-internal-fastdebug-ed_2014_01_07_17_03-b00) OpenJDK 64-Bit Server VM (build 25.0-b59-fastdebug, mixed mode) Regards, Ed. From thuhc at yahoo.com Wed Jan 8 05:56:17 2014 From: thuhc at yahoo.com (Cao Hoang Thu) Date: Wed, 8 Jan 2014 05:56:17 -0800 (PST) Subject: [aarch64-port-dev ] TestStackBangRbp hangs In-Reply-To: <1389179919.27478.20.camel@localhost.localdomain> Message-ID: <1389189377.22775.YahooMailBasic@web164604.mail.gq1.yahoo.com> Hi Ed, With C2 on RTSM --> hang indefinitely all test-cases With C1 on RTSM--> java -Xcomp TestStackBangRbp -> hang java -Xcomp -XX:-DeoptimizeWhenPatching TestStackBangRbp --> test passes Regards, Thu Cao -------------------------------------------- On Wed, 1/8/14, Edward Nevill wrote: Subject: [aarch64-port-dev ] TestStackBangRbp hangs To: "aarch64-port-dev at openjdk.java.net" Date: Wednesday, January 8, 2014, 6:18 PM Hi, The following test program causes openjdk to hang indefinitely requiring a kill -9 to stop the process. To replicate - compile the test program javac TestStackBangRbp.java - run it as follows java -Xcomp TestStackBangRbp Note that the problem occurs for both client and server and also occurs on both builtin sim and on the RTSM model. If you add java -Xcomp -XX:+PrintCompilation -XX:+TracePatching TestStackBangRbp the last few lines of the output look like ???8291? 368? ? b? ? ? ? TestStackBangRbp:: (86 bytes) Deoptimizing because patch is needed ???8302? 368? ? ? ? ? ???TestStackBangRbp:: (86 bytes)???made not entrant ???8303? 369? ? b? ? ? ? TestStackBangRbp::main (38 bytes) ???8341? 370? ? b? ? ? ? TestStackBangRbp::m1 (246 bytes) ???8375? 371???!b? ? ? ? TestStackBangRbp::m2 (35 bytes) Deoptimizing because patch is needed ???8463? 371???!? ? ? ???TestStackBangRbp::m2 (35 bytes)???made not entrant If I then add -XX:-DeoptimizeWhenPatching, IE java -Xcomp -XX:-DeoptimizeWhenPatching TestStackBangRbp The test passes. So it looks like a problem with stack overflow when deoptimizing (or having just deoptimized). Looks like fun:-). Ed. From thuhc at yahoo.com Wed Jan 8 06:44:27 2014 From: thuhc at yahoo.com (Cao Hoang Thu) Date: Wed, 8 Jan 2014 06:44:27 -0800 (PST) Subject: [aarch64-port-dev ] Generating Nimbus source files error and some warings on x86_64 In-Reply-To: <1389189377.22775.YahooMailBasic@web164604.mail.gq1.yahoo.com> Message-ID: <1389192267.87018.YahooMailBasic@web164606.mail.gq1.yahoo.com> My configure: export OPENJDK8_DEBUG_LEVEL=release export OPENJDK8_JVM_VARIANTS=client,server export HOST_JDK_HOME=/usr/lib/jvm/jdk1.7.0_25 ./configure \ --with-debug-level=$OPENJDK8_DEBUG_LEVEL \ --with-jvm-variants=$OPENJDK8_JVM_VARIANTS \ --enable-unlimited-crypto \ --with-cacerts-file=$HOST_JDK_HOME/jre/lib/security/cacerts \ --with-stdc++lib=dynamic \ --with-boot-jdk=$HOST_JDK_HOME \ --disable-ccache When I compile openjdk8 on x86_64, I saw error: Generating Nimbus source files [Error] encoded value was less than 0: encode(-8.326673E-17, 5.0, 11.0, 16.0) [Error] encoded value was less than 0: encode(-0.05882353, 1.0, 24.0, 25.0) [Error] encoded value was greater than 3: encode(15.029411, 1.0, 14.0, 15.0) [Error] encoded value was less than 0: encode(-0.05882353, 1.0, 24.0, 25.0) [Error] encoded value was greater than 3: encode(15.029411, 1.0, 14.0, 15.0) [Error] encoded value was less than 0: encode(-0.05882353, 1.0, 24.0, 25.0) [Error] encoded value was less than 0: encode(-0.05882353, 1.0, 24.0, 25.0) [Error] encoded value was greater than 3: encode(15.029411, 1.0, 14.0, 15.0) [Error] encoded value was less than 0: encode(-0.05882353, 1.0, 24.0, 25.0) [Error] encoded value was greater than 3: encode(15.029411, 1.0, 14.0, 15.0) [Error] encoded value was less than 0: encode(-0.05882353, 1.0, 24.0, 25.0) [Error] encoded value was less than 0: encode(-0.05882353, 1.0, 24.0, 25.0) [Error] encoded value was greater than 3: encode(15.029411, 1.0, 14.0, 15.0) [Error] encoded value was less than 0: encode(-0.05882353, 1.0, 24.0, 25.0) [Error] encoded value was greater than 3: encode(15.029411, 1.0, 14.0, 15.0) [Error] encoded value was less than 0: encode(-0.05882353, 1.0, 24.0, 25.0) [Error] Encountered Infinity: encode(-0.00877193, 0.0, 7.0, 7.0) ................................ ## Starting images Creating images/lib/charsets.jar Creating images/lib/ext/cldrdata.jar Creating images/lib/ext/dnsns.jar Creating images/lib/ext/localedata.jar Creating images/lib/jsse.jar Creating images/lib/jconsole.jar Creating images/lib/dt.jar Creating images/lib/tools.jar Updating images/sec-bin.zip WARNING: Path does not exist as file or directory: sun/dc/DuctusRenderingEngine.class WARNING: Path does not exist as file or directory: sun/dc/path/PathConsumer.class WARNING: Path does not exist as file or directory: sun/dc/pr/PathDasher.class WARNING: Path does not exist as file or directory: sun/dc/pr/PathDasher$1.class WARNING: Path does not exist as file or directory: sun/dc/pr/PathStroker.class WARNING: Path does not exist as file or directory: sun/dc/pr/PathStroker$1.class WARNING: Path does not exist as file or directory: sun/font/T2KFontScaler.class WARNING: Path does not exist as file or directory: sun/font/T2KFontScaler$1.class WARNING: Path does not exist as file or directory: sun/misc/PostVMInitHook.class WARNING: Path does not exist as file or directory: com/sun/crypto/provider WARNING: Path does not exist as file or directory: com/sun/java/accessibility WARNING: Path does not exist as file or directory: javax/crypto WARNING: Path does not exist as file or directory: sun/security/ec WARNING: Path does not exist as file or directory: sun/security/internal WARNING: Path does not exist as file or directory: sun/security/mscapi WARNING: Path does not exist as file or directory: sun/security/pkcs11 WARNING: Path does not exist as file or directory: com/oracle/jrockit/jfr WARNING: Path does not exist as file or directory: oracle/jrockit/jfr WARNING: Path does not exist as file or directory: jdk/jfr Updating images/src.zip Creating rt.jar Compressed=false Creating resources.jar warning: package javax.crypto does not exist warning: package javax.crypto.interfaces does not exist warning: package javax.crypto.spec does not exist warning: package javax.tools.annotation does not exist warning: package com.oracle.nio does not exist Using boot class path = [/home/thcao/ws/openjdk8-aarch64/build/linux-x86_64-normal-clientANDserver-release/images/lib/rt.jar, /home/thcao/ws/openjdk8-aarch64/build/linux-x86_64-normal-clientANDserver-release/langtools/dist/bootstrap/lib/javac.jar, /usr/lib/jvm/jdk1.7.0_25/jre/lib/resources.jar, /usr/lib/jvm/jdk1.7.0_25/jre/lib/sunrsasign.jar, /usr/lib/jvm/jdk1.7.0_25/jre/lib/jsse.jar, /usr/lib/jvm/jdk1.7.0_25/jre/lib/jce.jar, /usr/lib/jvm/jdk1.7.0_25/jre/lib/charsets.jar, /usr/lib/jvm/jdk1.7.0_25/jre/lib/jfr.jar, /usr/lib/jvm/jdk1.7.0_25/jre/classes, /usr/lib/jvm/jdk1.7.0_25/jre/lib/ext/sunjce_provider.jar, /usr/lib/jvm/jdk1.7.0_25/jre/lib/ext/zipfs.jar, /usr/lib/jvm/jdk1.7.0_25/jre/lib/ext/sunec.jar, /usr/lib/jvm/jdk1.7.0_25/jre/lib/ext/dnsns.jar, /usr/lib/jvm/jdk1.7.0_25/jre/lib/ext/sunpkcs11.jar, /usr/lib/jvm/jdk1.7.0_25/jre/lib/ext/localedata.jar] Ignoring (other) com.sun.management.package-info : ClassSymbol Ignoring (other) com.sun.net.httpserver.package-info : ClassSymbol Ignoring (other) com.sun.net.httpserver.spi.package-info : ClassSymbol Ignoring (other) com.sun.nio.sctp.package-info : ClassSymbol Ignoring (other) com.sun.security.auth.package-info : ClassSymbol Ignoring (other) com.sun.security.auth.callback.package-info : ClassSymbol Ignoring (other) com.sun.security.auth.login.package-info : ClassSymbol Ignoring (other) com.sun.security.auth.module.package-info : ClassSymbol Ignoring (other) com.sun.security.jgss.package-info : ClassSymbol Ignoring (other) javax.xml.ws.wsaddressing.package-info : ClassSymbol 5 warnings Do they effect jvm after build ? Regards, Thu Cao From ed at camswl.com Wed Jan 8 07:20:23 2014 From: ed at camswl.com (Edward Nevill) Date: Wed, 08 Jan 2014 15:20:23 +0000 Subject: [aarch64-port-dev ] SPECjvm2008 xml.validation fails with -XX:+UseBiasedLocking Message-ID: <1389194423.27478.43.camel@localhost.localdomain> Hi, Setup is as follows. On the RTSM model only. This failure is not repeatable with the builtin sim. /home/ed/images/j2sdk-client-slowdebug/bin/java -version ~/SPECjvm2008$ /home/ed/images/j2sdk-client-slowdebug/bin/java -version openjdk version "1.8.0-internal-debug" OpenJDK Runtime Environment (build 1.8.0-internal-debug-ed_2014_01_07_10_53-b00) OpenJDK 64-Bit Client VM (build 25.0-b59-debug, mixed mode) Command taskset 10 /home/ed/images/j2sdk-client-slowdebug/bin/java -XX:+UseBiasedLocking -jar SPECjvm2008.jar -bt 16 -ikv xml.validation produces the error # Internal Error (/home/ed/work/rc3/jdk8/hotspot/src/share/vm/runtime/synchronizer.cpp:1297), pid=14154, tid=546926752240 # assert(dmw->is_neutral()) failed: invariant The failure does not happen every time, but with taskset 10 and -bt 16 it seems fairly dependable (I have just run it 6 times in a row and it has failed every time). taskset 10 tells it to use a single core (ie. core 5) -bt 16 tells it to run the benchmark as 16 threads. The problem does not seem to occur without the taskset 10, ie. it seems to be running multi threaded single core that provokes it. The problem is more frequent the higher the -bt N value, but making it too high causes out of memory errors. Slowdebug seems to provoke the problem more than fastdebug, although this may just be my perception. All the best, Ed. From aph at redhat.com Wed Jan 8 08:04:39 2014 From: aph at redhat.com (Andrew Haley) Date: Wed, 08 Jan 2014 16:04:39 +0000 Subject: [aarch64-port-dev ] TestStackBangRbp hangs In-Reply-To: <52CD3FDC.70602@redhat.com> References: <1389179919.27478.20.camel@localhost.localdomain> <52CD3D9C.9050208@redhat.com> <52CD3ECA.40106@redhat.com> <52CD3FDC.70602@redhat.com> Message-ID: <52CD7717.7040503@redhat.com> On 01/08/2014 12:09 PM, Andrew Haley wrote: > On 01/08/2014 12:04 PM, Andrew Dinn wrote: >> >> >> On 08/01/14 11:59, Andrew Haley wrote: >>> On 01/08/2014 11:18 AM, Edward Nevill wrote: >>>> If I then add -XX:-DeoptimizeWhenPatching, IE >>>> >>>> java -Xcomp -XX:-DeoptimizeWhenPatching TestStackBangRbp >>>> >>>> The test passes. >>>> >>>> So it looks like a problem with stack overflow when deoptimizing (or having just deoptimized). >>> >>> You didn't say what your configured target was; I guess C1. >> >> Perhaps not as the code includes a comment about forcing a deopt in C2 > > Well, the OP says either; but both work for me. ... but not always. I'm on it. Andrew. From edward.nevill at linaro.org Wed Jan 8 08:28:05 2014 From: edward.nevill at linaro.org (Edward Nevill) Date: Wed, 08 Jan 2014 16:28:05 +0000 Subject: [aarch64-port-dev ] Generating Nimbus source files error and some warings on x86_64 In-Reply-To: <1389192267.87018.YahooMailBasic@web164606.mail.gq1.yahoo.com> References: <1389192267.87018.YahooMailBasic@web164606.mail.gq1.yahoo.com> Message-ID: <1389198485.13354.6.camel@localhost.localdomain> Hi Thu Cao, I have just done a build of the openjdk trunk and I get the same errors (with some more) so I am not overly concerned about these. All the best, Ed. On Wed, 2014-01-08 at 06:44 -0800, Cao Hoang Thu wrote: > Updating images/sec-bin.zip > WARNING: Path does not exist as file or directory: sun/dc/DuctusRenderingEngine.class > WARNING: Path does not exist as file or directory: sun/dc/path/PathConsumer.class > WARNING: Path does not exist as file or directory: sun/dc/pr/PathDasher.class > WARNING: Path does not exist as file or directory: sun/dc/pr/PathDasher$1.class > WARNING: Path does not exist as file or directory: sun/dc/pr/PathStroker.class > WARNING: Path does not exist as file or directory: sun/dc/pr/PathStroker$1.class > WARNING: Path does not exist as file or directory: sun/font/T2KFontScaler.class > WARNING: Path does not exist as file or directory: sun/font/T2KFontScaler$1.class > WARNING: Path does not exist as file or directory: sun/misc/PostVMInitHook.class > WARNING: Path does not exist as file or directory: com/sun/crypto/provider > WARNING: Path does not exist as file or directory: com/sun/java/accessibility > WARNING: Path does not exist as file or directory: javax/crypto > WARNING: Path does not exist as file or directory: sun/security/ec > WARNING: Path does not exist as file or directory: sun/security/internal > WARNING: Path does not exist as file or directory: sun/security/mscapi > WARNING: Path does not exist as file or directory: sun/security/pkcs11 > WARNING: Path does not exist as file or directory: com/oracle/jrockit/jfr > WARNING: Path does not exist as file or directory: oracle/jrockit/jfr > WARNING: Path does not exist as file or directory: jdk/jfr > Updating images/src.zip > Creating rt.jar Compressed=false > Creating resources.jar > warning: package javax.crypto does not exist > warning: package javax.crypto.interfaces does not exist > warning: package javax.crypto.spec does not exist > warning: package javax.tools.annotation does not exist > warning: package com.oracle.nio does not exist > Using boot class path = [/home/thcao/ws/openjdk8-aarch64/build/linux-x86_64-normal-clientANDserver-release/images/lib/rt.jar, /home/thcao/ws/openjdk8-aarch64/build/linux-x86_64-normal-clientANDserver-release/langtools/dist/bootstrap/lib/javac.jar, /usr/lib/jvm/jdk1.7.0_25/jre/lib/resources.jar, /usr/lib/jvm/jdk1.7.0_25/jre/lib/sunrsasign.jar, /usr/lib/jvm/jdk1.7.0_25/jre/lib/jsse.jar, /usr/lib/jvm/jdk1.7.0_25/jre/lib/jce.jar, /usr/lib/jvm/jdk1.7.0_25/jre/lib/charsets.jar, /usr/lib/jvm/jdk1.7.0_25/jre/lib/jfr.jar, /usr/lib/jvm/jdk1.7.0_25/jre/classes, /usr/lib/jvm/jdk1.7.0_25/jre/lib/ext/sunjce_provider.jar, /usr/lib/jvm/jdk1.7.0_25/jre/lib/ext/zipfs.jar, /usr/lib/jvm/jdk1.7.0_25/jre/lib/ext/sunec.jar, /usr/lib/jvm/jdk1.7.0_25/jre/lib/ext/dnsns.jar, /usr/lib/jvm/jdk1.7.0_25/jre/lib/ext/sunpkcs11.jar, /usr/lib/jvm/jdk1.7.0_25/jre/lib/ext/localedata.jar] > Ignoring (other) com.sun.management.package-info : > ClassSymbol > Ignoring (other) com.sun.net.httpserver.package-info : > ClassSymbol > Ignoring (other) com.sun.net.httpserver.spi.package-info : > ClassSymbol > Ignoring (other) com.sun.nio.sctp.package-info : > ClassSymbol > Ignoring (other) com.sun.security.auth.package-info : > ClassSymbol > Ignoring (other) com.sun.security.auth.callback.package-info : > ClassSymbol > Ignoring (other) com.sun.security.auth.login.package-info : > ClassSymbol > Ignoring (other) com.sun.security.auth.module.package-info : > ClassSymbol > Ignoring (other) com.sun.security.jgss.package-info : > ClassSymbol > Ignoring (other) javax.xml.ws.wsaddressing.package-info : > ClassSymbol > 5 warnings > > Do they effect jvm after build ? > > Regards, > Thu Cao From ed at camswl.com Thu Jan 9 02:00:52 2014 From: ed at camswl.com (Edward Nevill) Date: Thu, 09 Jan 2014 10:00:52 +0000 Subject: [aarch64-port-dev ] SPECjvm2008 derby gives SIGBUS with -XX:+TieredCompilation Message-ID: <1389261652.823.9.camel@localhost.localdomain> Hi, On the RTSM model I get a SIGBUS from the 'derby' benchmark in SPECjvm2008 running -XX:+TieredCompilation. This seems to be 100% reproducible on the RTSM model but I cannot reproduce it on the builtin sim. My version of java is ~/SPECjvm2008$ /home/ed/images/j2sdk-server-fastdebug/bin/java -version openjdk version "1.8.0-internal-fastdebug" OpenJDK Runtime Environment (build 1.8.0-internal-fastdebug-ed_2014_01_07_17_03-b00) OpenJDK 64-Bit Server VM (build 25.0-b59-fastdebug, mixed mode) The command I use is /home/ed/images/j2sdk-server-fastdebug/bin/java -XX:+TieredCompilation -jar SPECjvm2008.jar -ikv derby This seems to run reliably if I use -bt 1 (ie to run the benchmark in 1 thread instead of the default of 8). The following is a sample output from the test. # # A fatal error has been detected by the Java Runtime Environment: # # SIGBUS (0x7) at pc=0x0000007f852c31a4, pid=2180, tid=547367154160 # # JRE version: OpenJDK Runtime Environment (8.0) (build 1.8.0-internal-fastdebug-ed_2014_01_07_17_03-b00) # Java VM: OpenJDK 64-Bit Server VM (25.0-b59-fastdebug mixed mode linux-aarch64 compressed oops) # Problematic frame: # J 4055 C1 java.util.concurrent.locks.AbstractQueuedSynchronizer.addWaiter(Ljava/util/concurrent/locks/AbstractQueuedSynchronizer$Node;)Ljava/util/concurrent/locks/AbstractQueuedSynchronizer$Node; (50 bytes) @ 0x0000007f852c31a4 [0x0000007f852c2f20+0x284] # # 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: # /home/ed/SPECjvm2008/hs_err_pid2180.log # # If you would like to submit a bug report, please visit: # http://bugreport.sun.com/bugreport/crash.jsp # Current thread is 547367154160 Dumping core ... LOOPING... [thread 547373445616 also had an error] [thread 547377639920 also had an error] All the best, Ed. From adinn at redhat.com Fri Jan 10 03:31:34 2014 From: adinn at redhat.com (adinn at redhat.com) Date: Fri, 10 Jan 2014 11:31:34 +0000 Subject: [aarch64-port-dev ] hg: aarch64-port/jdk8/hotspot: Add support for target JDK 7 Message-ID: <20140110113140.C1BAD624B9@hg.openjdk.java.net> Changeset: c40a7ed7df16 Author: adinn Date: 2014-01-10 11:31 +0000 URL: http://hg.openjdk.java.net/aarch64-port/jdk8/hotspot/rev/c40a7ed7df16 Add support for target JDK 7 add TARGET_JDK_VERSION=7 on the command line to build a version of libjvm.so which will support execution using JDK7 ! make/linux/makefiles/aarch64.make ! make/linux/makefiles/vm.make ! src/share/vm/prims/jvm.cpp ! src/share/vm/prims/jvm.h From aph at redhat.com Mon Jan 13 03:55:10 2014 From: aph at redhat.com (Andrew Haley) Date: Mon, 13 Jan 2014 11:55:10 +0000 Subject: [aarch64-port-dev ] TestStackBangRbp hangs In-Reply-To: <1389179919.27478.20.camel@localhost.localdomain> References: <1389179919.27478.20.camel@localhost.localdomain> Message-ID: <52D3D41E.6020305@redhat.com> On 01/08/2014 11:18 AM, Edward Nevill wrote: > Hi, > > The following test program causes openjdk to hang indefinitely requiring a kill -9 to stop the process. > > To replicate > > - compile the test program > > javac TestStackBangRbp.java > > - run it as follows > > java -Xcomp TestStackBangRbp > > Note that the problem occurs for both client and server and also occurs on both builtin sim and on the RTSM model. This was a real head-scratcher. It turns out that there were three separate bugs. This one in shared code: http://mail.openjdk.java.net/pipermail/hotspot-compiler-dev/2014-January/012938.html And two others in AArch64-specific code. The problem was that when we returned from deoptimizing we were not properly removing the stack frame of the deoptimized method. All we were doing was: // Pop deoptimized frame __ ldrw(r2, Address(r5, Deoptimization::UnrollBlock::size_of_deoptimized_frame_offset_in_bytes())); __ add(sp, sp, r2); Clearly, this does not work. We much also restore SP and LR. We need to do this: // Pop deoptimized frame __ ldrw(r2, Address(r5, Deoptimization::UnrollBlock::size_of_deoptimized_frame_offset_in_bytes())); __ sub(r2, r2, 2 * wordSize); __ add(sp, sp, r2); __ ldp(rfp, lr, __ post(sp, 2 * wordSize)); But -- amazingly -- there hardly ever was a failure caused by this fundamental mistake. This same bug was present in SharedRuntime::generate_deopt_blob() and SharedRuntime::generate_uncommon_trap_blob(). I suppose the code was copied from one to another, or maybe it was a common programmer thinko. The rest of this patch is tidying up as I want along and some debugging improvements to the simulator environment that I had to make in order to find the bug. Andrew. # HG changeset patch # User aph # Date 1389382344 0 # Node ID 277edfed6a723b4067f78a18544188261f540a35 # Parent 8ccf0e9d5070bda73a13e05f10fbd6b8e3154e8d Properly restore frames when deoptimizing. When removing a frame in the deoptimization handler, be sure to restore LR anf FP. Ensure compiled native methods begin with a NOP. Notify simulator of deoptimization blobs. diff -r 8ccf0e9d5070 -r 277edfed6a72 src/cpu/aarch64/vm/sharedRuntime_aarch64.cpp --- a/src/cpu/aarch64/vm/sharedRuntime_aarch64.cpp Fri Jan 10 19:30:52 2014 +0000 +++ b/src/cpu/aarch64/vm/sharedRuntime_aarch64.cpp Fri Jan 10 19:32:24 2014 +0000 @@ -1542,12 +1542,14 @@ int vep_offset = ((intptr_t)__ pc()) - start; - // The instruction at the verified entry point must be 5 bytes or longer - // because it can be patched on the fly by make_non_entrant. The stack bang - // instruction fits that requirement. - // Generate stack overflow check + // If we have to make this method not-entrant we'll overwrite its + // first instruction with a jump. For this action to be legal we + // must ensure that this first instruction is a B, BL, NOP, BKPT, + // SVC, HVC, or SMC. Make it a NOP. + __ nop(); + if (UseStackBanging) { __ bang_stack_with_offset(StackShadowPages*os::vm_page_size()); } else { @@ -1993,7 +1995,7 @@ Label reguard; Label reguard_done; - __ ldrw(rscratch1, Address(rthread, JavaThread::stack_guard_state_offset())); + __ ldrb(rscratch1, Address(rthread, JavaThread::stack_guard_state_offset())); __ cmpw(rscratch1, JavaThread::stack_guard_yellow_disabled); __ br(Assembler::EQ, reguard); __ bind(reguard_done); @@ -2251,6 +2253,14 @@ OopMap* map = NULL; OopMapSet *oop_maps = new OopMapSet(); +#ifdef BUILTIN_SIM + AArch64Simulator *simulator; + if (NotifySimulator) { + simulator = AArch64Simulator::get_current(UseSimulatorCache, DisableBCCheck); + simulator->notifyCompile(const_cast("SharedRuntime::deopt_blob"), __ pc()); + } +#endif + // ------------- // This code enters when returning to a de-optimized nmethod. A return // address has been pushed on the the stack, and return values are in @@ -2436,9 +2446,10 @@ // Pop deoptimized frame __ ldrw(r2, Address(r5, Deoptimization::UnrollBlock::size_of_deoptimized_frame_offset_in_bytes())); + __ sub(r2, r2, 2 * wordSize); __ add(sp, sp, r2); - - // sp should be pointing at the return address to the caller (3) + __ ldp(rfp, lr, __ post(sp, 2 * wordSize)); + // LR should now be the return address to the caller (3) // Stack bang to make sure there's enough room for these interpreter frames. if (UseStackBanging) { @@ -2544,6 +2555,13 @@ _deopt_blob = DeoptimizationBlob::create(&buffer, oop_maps, 0, exception_offset, reexecute_offset, frame_size_in_words); _deopt_blob->set_unpack_with_exception_in_tls_offset(exception_in_tls_offset); + +#ifdef BUILTIN_SIM + if (NotifySimulator) { + unsigned char *base = _deopt_blob->code_begin(); + simulator->notifyRelocate(start, base - start); + } +#endif } uint SharedRuntime::out_preserve_stack_slots() { @@ -2559,6 +2577,14 @@ CodeBuffer buffer("uncommon_trap_blob", 2048, 1024); MacroAssembler* masm = new MacroAssembler(&buffer); +#ifdef BUILTIN_SIM + AArch64Simulator *simulator; + if (NotifySimulator) { + simulator = AArch64Simulator::get_current(UseSimulatorCache, DisableBCCheck); + simulator->notifyCompile(const_cast("SharedRuntime:uncommon_trap_blob"), __ pc()); + } +#endif + // TODO check various assumptions here // // call unimplemented to make sure we actually check this later @@ -2631,9 +2657,10 @@ __ ldrw(r2, Address(r4, Deoptimization::UnrollBlock:: size_of_deoptimized_frame_offset_in_bytes())); + __ sub(r2, r2, 2 * wordSize); __ add(sp, sp, r2); - - // sp should now be pointing at the top of the caller (3) frame + __ ldp(rfp, lr, __ post(sp, 2 * wordSize)); + // LR should now be the return address to the caller (3) frame // Stack bang to make sure there's enough room for these interpreter frames. if (UseStackBanging) { @@ -2734,6 +2761,13 @@ _uncommon_trap_blob = UncommonTrapBlob::create(&buffer, oop_maps, SimpleRuntimeFrame::framesize >> 1); + +#ifdef BUILTIN_SIM + if (NotifySimulator) { + unsigned char *base = _deopt_blob->code_begin(); + simulator->notifyRelocate(start, base - start); + } +#endif } #endif // COMPILER2 @@ -2744,7 +2778,7 @@ // and setup oopmap. // SafepointBlob* SharedRuntime::generate_handler_blob(address call_ptr, int poll_type) { - ResourceMark rm; + ResourceMark rm; OopMapSet *oop_maps = new OopMapSet(); OopMap* map; diff -r 8ccf0e9d5070 -r 277edfed6a72 src/cpu/aarch64/vm/templateInterpreter_aarch64.cpp --- a/src/cpu/aarch64/vm/templateInterpreter_aarch64.cpp Fri Jan 10 19:30:52 2014 +0000 +++ b/src/cpu/aarch64/vm/templateInterpreter_aarch64.cpp Fri Jan 10 19:32:24 2014 +0000 @@ -1016,11 +1016,10 @@ __ bind(no_oop); } - { Label no_reguard; __ lea(rscratch1, Address(rthread, in_bytes(JavaThread::stack_guard_state_offset()))); - __ ldrw(rscratch1, Address(rscratch1)); + __ ldrb(rscratch1, Address(rscratch1)); __ cmp(rscratch1, JavaThread::stack_guard_yellow_disabled); __ br(Assembler::NE, no_reguard); @@ -1029,11 +1028,9 @@ __ mov(rscratch2, CAST_FROM_FN_PTR(address, SharedRuntime::reguard_yellow_pages)); __ blrt(rscratch2, 0, 0, 0); __ popa(); // XXX only restore smashed registers - __ reinit_heapbase(); __ bind(no_reguard); } - // The method register is junk from after the thread_in_native transition // until here. Also can't call_VM until the bcp has been // restored. Need bcp for throwing exception below so get it now. From adinn at redhat.com Mon Jan 13 05:37:51 2014 From: adinn at redhat.com (Andrew Dinn) Date: Mon, 13 Jan 2014 13:37:51 +0000 Subject: [aarch64-port-dev ] TestStackBangRbp hangs In-Reply-To: <52D3D41E.6020305@redhat.com> References: <1389179919.27478.20.camel@localhost.localdomain> <52D3D41E.6020305@redhat.com> Message-ID: <52D3EC2F.3050206@redhat.com> On 13/01/14 11:55, Andrew Haley wrote: > It turns out that there were three separate bugs. > > This one in shared code: > > http://mail.openjdk.java.net/pipermail/hotspot-compiler-dev/2014-January/012938.html Yes, that makes sense. > And two others in AArch64-specific code. The problem was that when we > returned from deoptimizing we were not properly removing the stack > frame of the deoptimized method. All we were doing was: > > // Pop deoptimized frame > __ ldrw(r2, Address(r5, Deoptimization::UnrollBlock::size_of_deoptimized_frame_offset_in_bytes())); > __ add(sp, sp, r2); > > Clearly, this does not work. We much also restore SP and LR. We need > to do this: That doesn't make sense to me. Why do we need to restore SP and LR? They get reset later (see below). > // Pop deoptimized frame > __ ldrw(r2, Address(r5, Deoptimization::UnrollBlock::size_of_deoptimized_frame_offset_in_bytes())); > __ sub(r2, r2, 2 * wordSize); > __ add(sp, sp, r2); > __ ldp(rfp, lr, __ post(sp, 2 * wordSize)); > > But -- amazingly -- there hardly ever was a failure caused by this > fundamental mistake. In the deopt case rfp and lr are patched up after the interpreter frames have been pushed i.e. at line 2660: // Pick up the initial fp we should save __ ldr(rfp, Address(r4, Deoptimization::UnrollBlock::initial_info_offset_in_bytes())); and at line 2694: __ ldr(lr, Address(r2, 0)); // save final return address // Re-push self-frame __ enter(); // & old rfp & set new rfp Also, if you do want to load rfp and lr asd above then would it not be better to subtract r2 as is and then do the load pair with an immediate offset of -2 * wordsize? // Pop deoptimized frame __ ldrw(r2, Address(r5, Deoptimization::UnrollBlock::size_of_deoptimized_frame_offset_in_bytes())); __ add(sp, sp, r2); __ ldp(rfp, lr, Address(sp, -2 * wordSize)); > This same bug was present in SharedRuntime::generate_deopt_blob() and > SharedRuntime::generate_uncommon_trap_blob(). I suppose the code was > copied from one to another, or maybe it was a common programmer > thinko. In fact, they were all copied from the corresponding x86 code which also does not bother to do anything with the frame pointer or return address. regards, Andrew Dinn ----------- From aph at redhat.com Mon Jan 13 05:57:42 2014 From: aph at redhat.com (Andrew Haley) Date: Mon, 13 Jan 2014 13:57:42 +0000 Subject: [aarch64-port-dev ] TestStackBangRbp hangs In-Reply-To: <52D3EC2F.3050206@redhat.com> References: <1389179919.27478.20.camel@localhost.localdomain> <52D3D41E.6020305@redhat.com> <52D3EC2F.3050206@redhat.com> Message-ID: <52D3F0D6.5070600@redhat.com> On 01/13/2014 01:37 PM, Andrew Dinn wrote: > On 13/01/14 11:55, Andrew Haley wrote: >> It turns out that there were three separate bugs. >> >> This one in shared code: >> >> http://mail.openjdk.java.net/pipermail/hotspot-compiler-dev/2014-January/012938.html > > Yes, that makes sense. > >> And two others in AArch64-specific code. The problem was that when we >> returned from deoptimizing we were not properly removing the stack >> frame of the deoptimized method. All we were doing was: >> >> // Pop deoptimized frame >> __ ldrw(r2, Address(r5, Deoptimization::UnrollBlock::size_of_deoptimized_frame_offset_in_bytes())); >> __ add(sp, sp, r2); >> >> Clearly, this does not work. We much also restore SP and LR. We need >> to do this: > > That doesn't make sense to me. Why do we need to restore SP and LR? They > get reset later (see below). > >> // Pop deoptimized frame >> __ ldrw(r2, Address(r5, Deoptimization::UnrollBlock::size_of_deoptimized_frame_offset_in_bytes())); >> __ sub(r2, r2, 2 * wordSize); >> __ add(sp, sp, r2); >> __ ldp(rfp, lr, __ post(sp, 2 * wordSize)); >> >> But -- amazingly -- there hardly ever was a failure caused by this >> fundamental mistake. > > In the deopt case rfp and lr are patched up after the interpreter frames > have been pushed i.e. at line 2660: > > // Pick up the initial fp we should save > __ ldr(rfp, > Address(r4, Deoptimization::UnrollBlock::initial_info_offset_in_bytes())); > > and at line 2694: > > __ ldr(lr, Address(r2, 0)); // save final return address > // Re-push self-frame > __ enter(); // & old rfp & set new rfp It's too late by then: bang_stack_size() on Line 2670 might have trapped, and it needs to see a valid stack when it throws the StackOverflowException. > Also, if you do want to load rfp and lr asd above then would it not be > better to subtract r2 as is and then do the load pair with an immediate > offset of -2 * wordsize? I wrote it that way first, and I thought this one was clearer. > // Pop deoptimized frame > __ ldrw(r2, Address(r5, > Deoptimization::UnrollBlock::size_of_deoptimized_frame_offset_in_bytes())); > __ add(sp, sp, r2); > __ ldp(rfp, lr, Address(sp, -2 * wordSize)); > >> This same bug was present in SharedRuntime::generate_deopt_blob() and >> SharedRuntime::generate_uncommon_trap_blob(). I suppose the code was >> copied from one to another, or maybe it was a common programmer >> thinko. > > In fact, they were all copied from the corresponding x86 code which also > does not bother to do anything with the frame pointer or return address. It doesn't need to because the return address is in memory, not on the stack, and that's where a backtrace will pick it up. AArch64 really needs to restore at least the return address and (for sanity checking) the FP. See SPARC for the equivalent code. Andrew. From adinn at redhat.com Wed Jan 15 10:54:10 2014 From: adinn at redhat.com (adinn at redhat.com) Date: Wed, 15 Jan 2014 18:54:10 +0000 Subject: [aarch64-port-dev ] hg: aarch64-port/jdk8/hotspot: modified make files so they respond to JDK_MINOR_VERSION Message-ID: <20140115185412.7802F62490@hg.openjdk.java.net> Changeset: d36f681e097d Author: adinn Date: 2014-01-15 18:30 +0000 URL: http://hg.openjdk.java.net/aarch64-port/jdk8/hotspot/rev/d36f681e097d modified make files so they respond to JDK_MINOR_VERSION JDK_MINOR_VERSION is automatically set to 7 by the JDK7 build system and 8 by the JDK8 built system. so we can use it to determine whether to insert -DTARGET_JDK_VERSION=7 into CFLAGS when compiling thehotspot tree. with this modification we can now replace the icedtea7 hotspot hg tree with the jdk8-aarch64 hotspot hg tree and build an x86 version of icedtea7. this is a preliminary step to being able to compile an aarch64 native Java release of JDK7 based on this hybrid tree. n.b. the setting of -DTARGET_JDK_VERSION=7 was moved from aarch64.make into vm.make so as to allow testing the x86 build. it ought to stay there so we can still retest this when we pull in new changes. ! make/linux/makefiles/aarch64.make ! make/linux/makefiles/vm.make From aph at redhat.com Thu Jan 16 06:41:27 2014 From: aph at redhat.com (Andrew Haley) Date: Thu, 16 Jan 2014 14:41:27 +0000 Subject: [aarch64-port-dev ] Enable TieredCompilation Message-ID: <52D7EF97.5090708@redhat.com> This seems to be the best default. Andrew. # HG changeset patch # User aph # Date 1389882934 18000 # Thu Jan 16 09:35:34 2014 -0500 # Node ID f003157aba15fef05d04bf8b1e30d4c5280b383e # Parent f930dd00af0bd1592cccfd47b1f79b85b3e6d48a Enable TieredCompilation. diff -r f930dd00af0b -r f003157aba15 src/cpu/aarch64/vm/c2_globals_aarch64.hpp --- a/src/cpu/aarch64/vm/c2_globals_aarch64.hpp Thu Jan 16 09:34:49 2014 -0500 +++ b/src/cpu/aarch64/vm/c2_globals_aarch64.hpp Thu Jan 16 09:35:34 2014 -0500 @@ -46,7 +46,7 @@ #else define_pd_global(bool, ProfileInterpreter, true); #endif // CC_INTERP -define_pd_global(bool, TieredCompilation, false); +define_pd_global(bool, TieredCompilation, trueInTiered); define_pd_global(intx, CompileThreshold, 10000); define_pd_global(intx, BackEdgeThreshold, 100000); From aph at redhat.com Thu Jan 16 06:44:46 2014 From: aph at redhat.com (Andrew Haley) Date: Thu, 16 Jan 2014 14:44:46 +0000 Subject: [aarch64-port-dev ] Implement handler_for_unsafe_access() Message-ID: <52D7F05E.1020908@redhat.com> Something we missed before now. It won't work with the built-in simulator, but is fine with the model. Making it work with the built- in simulator would be very fiddly, so I'm not going to attempt it. Andrew. # HG changeset patch # User aph # Date 1389882889 18000 # Thu Jan 16 09:34:49 2014 -0500 # Node ID f930dd00af0bd1592cccfd47b1f79b85b3e6d48a # Parent c40a7ed7df16bf529d6cd1b281699c7c520eaea5 Implement handler_for_unsafe_access(). diff -r c40a7ed7df16 -r f930dd00af0b src/cpu/aarch64/vm/stubGenerator_aarch64.cpp --- a/src/cpu/aarch64/vm/stubGenerator_aarch64.cpp Fri Jan 10 11:31:09 2014 +0000 +++ b/src/cpu/aarch64/vm/stubGenerator_aarch64.cpp Thu Jan 16 09:34:49 2014 -0500 @@ -67,9 +67,20 @@ // Stub Code definitions -#if 0 -static address handle_unsafe_access() { Unimplemented(); return 0; } -#endif +static address handle_unsafe_access() { + JavaThread* thread = JavaThread::current(); + address pc = thread->saved_exception_pc(); + // pc is the instruction which we must emulate + // doing a no-op is fine: return garbage from the load + // therefore, compute npc + address npc = pc + NativeCall::instruction_size; + + // request an async exception + thread->set_pending_unsafe_access_error(); + + // return address of next instruction to execute + return npc; +} class StubGenerator: public StubCodeGenerator { private: @@ -693,15 +704,19 @@ // asynchronous UnknownError when an unsafe access gets a fault that // could not be reasonably prevented by the programmer. (Example: // SIGBUS/OBJERR.) + address generate_handler_for_unsafe_access() { + StubCodeMark mark(this, "StubRoutines", "handler_for_unsafe_access"); + address start = __ pc(); - // NOTE: this is used by the signal handler code as a return address - // to re-enter Java execution so it needs an x86 prolog which will - // reenter the simulator executing the generated handler code. so - // the prolog needs to adjust the sim's restart pc to enter the - // generated code at the start position then return from native to - // simulated execution. + __ push(0x3fffffff, sp); // integer registers except lr & sp + BLOCK_COMMENT("call handle_unsafe_access"); + __ call_VM_leaf(CAST_FROM_FN_PTR(address, handle_unsafe_access)); + __ mov(lr, r0); + __ pop (0x3fffffff, sp); // integer registers except lr & sp + __ br(lr); - address generate_handler_for_unsafe_access() { return 0; } + return start; + } // Non-destructive plausibility checks for oops // @@ -893,7 +908,7 @@ __ mov(c_rarg0, start); __ mov(c_rarg1, scratch); __ call_VM_leaf(CAST_FROM_FN_PTR(address, BarrierSet::static_write_ref_array_post), 2); - __ pop(0x3fffffff, sp); // integer registers except lr & sp } + __ pop(0x3fffffff, sp); // integer registers except lr & sp } break; case BarrierSet::CardTableModRef: From aph at redhat.com Thu Jan 16 06:45:51 2014 From: aph at redhat.com (aph at redhat.com) Date: Thu, 16 Jan 2014 14:45:51 +0000 Subject: [aarch64-port-dev ] hg: aarch64-port/jdk8/hotspot: 3 new changesets Message-ID: <20140116144601.09B8E624BC@hg.openjdk.java.net> Changeset: f930dd00af0b Author: aph Date: 2014-01-16 09:34 -0500 URL: http://hg.openjdk.java.net/aarch64-port/jdk8/hotspot/rev/f930dd00af0b Implement handler_for_unsafe_access(). ! src/cpu/aarch64/vm/stubGenerator_aarch64.cpp Changeset: f003157aba15 Author: aph Date: 2014-01-16 09:35 -0500 URL: http://hg.openjdk.java.net/aarch64-port/jdk8/hotspot/rev/f003157aba15 Enable TieredCompilation. ! src/cpu/aarch64/vm/c2_globals_aarch64.hpp Changeset: da3932d96d4d Author: aph Date: 2014-01-16 09:45 -0500 URL: http://hg.openjdk.java.net/aarch64-port/jdk8/hotspot/rev/da3932d96d4d Merge From aph at redhat.com Thu Jan 16 06:50:38 2014 From: aph at redhat.com (aph at redhat.com) Date: Thu, 16 Jan 2014 14:50:38 +0000 Subject: [aarch64-port-dev ] hg: aarch64-port/jdk8/hotspot: 7 new changesets Message-ID: <20140116145053.66155624BD@hg.openjdk.java.net> Changeset: 8ccf0e9d5070 Author: aph Date: 2014-01-10 19:30 +0000 URL: http://hg.openjdk.java.net/aarch64-port/jdk8/hotspot/rev/8ccf0e9d5070 Reguard the stack when returning to a call stub. ! src/share/vm/runtime/sharedRuntime.cpp Changeset: 277edfed6a72 Author: aph Date: 2014-01-10 19:32 +0000 URL: http://hg.openjdk.java.net/aarch64-port/jdk8/hotspot/rev/277edfed6a72 Properly restore frames when deoptimizing. When removing a frame in the deoptimization handler, be sure to restore LR anf FP. Ensure compiled native methods begin with a NOP. Notify simulator of deoptimization blobs. ! src/cpu/aarch64/vm/sharedRuntime_aarch64.cpp ! src/cpu/aarch64/vm/templateInterpreter_aarch64.cpp Changeset: 8bb5f543e43e Author: aph Date: 2014-01-13 10:29 +0000 URL: http://hg.openjdk.java.net/aarch64-port/jdk8/hotspot/rev/8bb5f543e43e Back out 8ccf0e9d5070 ! src/share/vm/runtime/sharedRuntime.cpp Changeset: bac7fbbe3f90 Author: roland Date: 2014-01-08 09:49 +0100 URL: http://hg.openjdk.java.net/aarch64-port/jdk8/hotspot/rev/bac7fbbe3f90 8029873: compiler/uncommontrap/TestStackBangRbp.java crashes with SIGSEGV Summary: May end up in uncommon trap blob/deopt blob with unguarded stack Reviewed-by: kvn, twisti ! src/share/vm/runtime/deoptimization.cpp ! src/share/vm/runtime/sharedRuntime.cpp + test/compiler/uncommontrap/StackOverflowGuardPagesOff.java Changeset: af35d2f7c14d Author: aph Date: 2014-01-13 11:56 +0000 URL: http://hg.openjdk.java.net/aarch64-port/jdk8/hotspot/rev/af35d2f7c14d Comment change only ! src/share/vm/interpreter/interpreterRuntime.cpp Changeset: 35fe0e6b1e82 Author: aph Date: 2014-01-13 11:56 +0000 URL: http://hg.openjdk.java.net/aarch64-port/jdk8/hotspot/rev/35fe0e6b1e82 Merge Changeset: ed3b90bb3e4c Author: aph Date: 2014-01-16 14:50 +0000 URL: http://hg.openjdk.java.net/aarch64-port/jdk8/hotspot/rev/ed3b90bb3e4c Merge From aph at redhat.com Fri Jan 17 10:09:27 2014 From: aph at redhat.com (aph at redhat.com) Date: Fri, 17 Jan 2014 18:09:27 +0000 Subject: [aarch64-port-dev ] hg: aarch64-port/jdk8/jdk: Set ARCH_DATA_MODEL=64 for AArch64. Message-ID: <20140117181026.DEBBE62528@hg.openjdk.java.net> Changeset: 7ecf627b6625 Author: aph Date: 2014-01-17 13:09 -0500 URL: http://hg.openjdk.java.net/aarch64-port/jdk8/jdk/rev/7ecf627b6625 Set ARCH_DATA_MODEL=64 for AArch64. ! make/common/shared/Platform.gmk From aph at redhat.com Fri Jan 17 10:37:36 2014 From: aph at redhat.com (Andrew Haley) Date: Fri, 17 Jan 2014 18:37:36 +0000 Subject: [aarch64-port-dev ] Implement handler_for_unsafe_access() In-Reply-To: <52D7F05E.1020908@redhat.com> References: <52D7F05E.1020908@redhat.com> Message-ID: <52D97870.2060500@redhat.com> Yesterday's patch was broken in that it trashed LR, which breaks traps from leaf functions. This patch is simpler and returns directly from the fault handler to the instruction after the fault, preserving LR. Andrew. # HG changeset patch # User aph # Date 1389981621 18000 # Fri Jan 17 13:00:21 2014 -0500 # Node ID ebe1eb322f481c62c29ee8a823a6be8a9e7508d8 # Parent e11bc6e52e678ca5cb6c7d7688838221ed55fe92 Implement handler for unsafe access by returning directly just after the faulting insn. diff -r e11bc6e52e67 -r ebe1eb322f48 src/os_cpu/linux_aarch64/vm/os_linux_aarch64.cpp --- a/src/os_cpu/linux_aarch64/vm/os_linux_aarch64.cpp Fri Jan 17 12:58:25 2014 -0500 +++ b/src/os_cpu/linux_aarch64/vm/os_linux_aarch64.cpp Fri Jan 17 13:00:21 2014 -0500 @@ -211,6 +211,23 @@ extern "C" void FetchNResume () ; #endif +// An operation in Unsafe has faulted. We're going to return to the +// instruction after the faulting load or store. We also set +// pending_unsafe_access_error so that at some point in the future our +// user will get a helpful message. +static address handle_unsafe_access(JavaThread* thread, address pc) { + // pc is the instruction which we must emulate + // doing a no-op is fine: return garbage from the load + // therefore, compute npc + address npc = pc + NativeCall::instruction_size; + + // request an async exception + thread->set_pending_unsafe_access_error(); + + // return address of next instruction to execute + return npc; +} + extern "C" JNIEXPORT int JVM_handle_linux_signal(int sig, siginfo_t* info, @@ -363,7 +380,7 @@ CodeBlob* cb = CodeCache::find_blob_unsafe(pc); nmethod* nm = (cb != NULL && cb->is_nmethod()) ? (nmethod*)cb : NULL; if (nm != NULL && nm->has_unsafe_access()) { - stub = StubRoutines::handler_for_unsafe_access(); + stub = handle_unsafe_access(thread, pc); } } else @@ -384,7 +401,7 @@ } else if (thread->thread_state() == _thread_in_vm && sig == SIGBUS && /* info->si_code == BUS_OBJERR && */ thread->doing_unsafe_access()) { - stub = StubRoutines::handler_for_unsafe_access(); + stub = handle_unsafe_access(thread, pc); } // jni_fast_GetField can trap at certain pc's if a GC kicks in From aph at redhat.com Fri Jan 17 10:40:24 2014 From: aph at redhat.com (aph at redhat.com) Date: Fri, 17 Jan 2014 18:40:24 +0000 Subject: [aarch64-port-dev ] hg: aarch64-port/jdk8/hotspot: 3 new changesets Message-ID: <20140117184044.2865462529@hg.openjdk.java.net> Changeset: e11bc6e52e67 Author: aph Date: 2014-01-17 12:58 -0500 URL: http://hg.openjdk.java.net/aarch64-port/jdk8/hotspot/rev/e11bc6e52e67 Back out 6496. ! src/cpu/aarch64/vm/stubGenerator_aarch64.cpp Changeset: ebe1eb322f48 Author: aph Date: 2014-01-17 13:00 -0500 URL: http://hg.openjdk.java.net/aarch64-port/jdk8/hotspot/rev/ebe1eb322f48 Implement handler for unsafe access by returning directly just after the faulting insn. ! src/os_cpu/linux_aarch64/vm/os_linux_aarch64.cpp Changeset: 895bbf967b69 Author: aph Date: 2014-01-17 13:39 -0500 URL: http://hg.openjdk.java.net/aarch64-port/jdk8/hotspot/rev/895bbf967b69 Merge From edward.nevill at linaro.org Tue Jan 21 02:32:13 2014 From: edward.nevill at linaro.org (Edward Nevill) Date: Tue, 21 Jan 2014 10:32:13 +0000 Subject: [aarch64-port-dev ] SPECjvm2008 derby gives SIGBUS with -XX:+TieredCompilation In-Reply-To: <1389261652.823.9.camel@localhost.localdomain> References: <1389261652.823.9.camel@localhost.localdomain> Message-ID: <1390300333.19765.40.camel@localhost.localdomain> On Thu, 2014-01-09 at 10:00 +0000, Edward Nevill wrote: > Hi, > > On the RTSM model I get a SIGBUS from the 'derby' benchmark in SPECjvm2008 running -XX:+TieredCompilation. > > This seems to be 100% reproducible on the RTSM model but I cannot reproduce it on the builtin sim. > To follow up on this. It turns out not to be a problem with TieredCompilation as such. It is a problem with +CompressedOops in the client compiler. Normally, CompressedOops is disabled when running the client compiler, however when running TieredCompilation CompressOops gets enabled. I can replicate the behaviour with the client compiler only using the following command:- /home/ed/images/j2sdk-client-fastdebug/bin/java -Xmx4g -XX:+UseCompressedOops -XX:CompileThreshold=500 -XX:BackEdgeThreshold=50000 -jar SPECjvm2008.jar -ikv derby ....... Warmup (120s) begins: Fri Oct 13 12:35:15 UTC 2028 # # A fatal error has been detected by the Java Runtime Environment: # # SIGSEGV (0xb) at pc=0x0000007f8a7fddfc, pid=25454, tid=547381834224 # # JRE version: OpenJDK Runtime Environment (8.0) (build 1.8.0-internal-fastdebug-ed_2014_01_20_13_31-b00) # Java VM: OpenJDK 64-Bit Client VM (25.0-b59-fastdebug mixed mode linux-aarch64 compressed oops) # Problematic frame: # J 2482 C1 java.util.concurrent.locks.AbstractQueuedSynchronizer.enq(Ljava/util/concurrent/locks/AbstractQueuedSynchronizer$Node;)Ljava/util/concurrent/locks/AbstractQueuedSynchronizer$Node; (58 bytes) @ 0x0000007f8a7fddfc [0x0000007f8a7fdc60+0x19c] # ....... If I exclude the following method then it runs successfully when running +Tiered. java.util.concurrent.locks.AbstractQueuedSynchronizer::compareAndSetTail Here is a disassembly of the method when running +Tiered and -Tiered. I have tried eyeballing the code but I cannot see anything wrong. If anyone can see anything wrong with the code please let me know:-) Otherwise I will just continue investigating, All the best, Ed. --- +Tiered compilation (failing case) ---- [Entry Point] # {method} {0x0000007f5bd45b10} 'compareAndSetTail' '(Ljava/util/concurrent/locks/AbstractQueuedSynchronizer$Node;Ljava/util/concurrent/locks/AbstractQueuedSynchronizer$Node;)Z' in 'java/util/concurrent/locks/AbstractQueuedSynchronizer' # this: c_rarg1:c_rarg1 = 'java/util/concurrent/locks/AbstractQueuedSynchronizer' # parm0: c_rarg2:c_rarg2 = 'java/util/concurrent/locks/AbstractQueuedSynchronizer$Node' # parm1: c_rarg3:c_rarg3 = 'java/util/concurrent/locks/AbstractQueuedSynchronizer$Node' # [sp+0x50] (sp of caller) ;; block B1 [0, 0] 0x0000007f712e9880: ldr w8, [x1,#8] ; {no_reloc} 0x0000007f712e9884: lsl x8, x8, #3 0x0000007f712e9888: cmp x8, x9 0x0000007f712e988c: b.eq 0x0000007f712e9894 0x0000007f712e9890: b 0x0000007f71147b20 ; {runtime_call} 0x0000007f712e9894: nop 0x0000007f712e9898: nop 0x0000007f712e989c: nop [Verified Entry Point] 0x0000007f712e98a0: nop ;; 0xFFFFFFFFFFFF7000 0x0000007f712e98a4: movn x9, #0x8fff 0x0000007f712e98a8: ldr xzr, [sp,x9] 0x0000007f712e98ac: stp x29, x30, [sp,#-16]! 0x0000007f712e98b0: mov x29, sp 0x0000007f712e98b4: sub sp, sp, #0x40 0x0000007f712e98b8: ldr x0, 0x0000007f712e9860 ; {section_word} 0x0000007f712e98bc: ldr w4, [x0,#108] 0x0000007f712e98c0: add w4, w4, #0x8 0x0000007f712e98c4: str w4, [x0,#108] 0x0000007f712e98c8: ldr x0, 0x0000007f712e9868 ; {section_word} 0x0000007f712e98cc: and w4, w4, #0x1ff8 0x0000007f712e98d0: cmp w4, #0x0 ;; 24 branch [EQ] [CounterOverflowStub: 0x2936be28] 0x0000007f712e98d4: b.eq 0x0000007f712e9930 ;*getstatic unsafe ; - java.util.concurrent.locks.AbstractQueuedSynchronizer::compareAndSetTail at 0 (line 2294) ;; block B2 [0, 0] ;; block B0 [0, 12] 0x0000007f712e98d8: add x0, x1, #0x18 0x0000007f712e98dc: lsr x2, x2, #3 0x0000007f712e98e0: mov x9, x3 0x0000007f712e98e4: lsr x9, x9, #3 0x0000007f712e98e8: ldaxr w8, [x0] 0x0000007f712e98ec: cmp w8, w2 0x0000007f712e98f0: cset x8, ne 0x0000007f712e98f4: b.ne 0x0000007f712e9900 0x0000007f712e98f8: stlxr w8, w9, [x0] 0x0000007f712e98fc: cbnz x8, 0x0000007f712e98e8 0x0000007f712e9900: eor w1, w8, #0x1 0x0000007f712e9904: lsr x0, x0, #9 ;; 0x7F81B71000 0x0000007f712e9908: movz x2, #0x1000 0x0000007f712e990c: movk x2, #0x81b7, lsl #16 0x0000007f712e9910: movk x2, #0x7f, lsl #32 0x0000007f712e9914: strb wzr, [x0,x2,lsl #0] ;*invokevirtual compareAndSwapObject ; - java.util.concurrent.locks.AbstractQueuedSynchronizer::compareAndSetTail at 9 (line 2294) 0x0000007f712e9918: mov x0, x1 0x0000007f712e991c: add sp, sp, #0x40 0x0000007f712e9920: ldp x29, x30, [sp],#16 0x0000007f712e9924: adrp x8, 0x0000007f873e6000 ; {poll_return} 0x0000007f712e9928: ldr wzr, [x8,#256] ; {poll_return} 0x0000007f712e992c: ret --- CUT HERE --- --- -TieredCompilation (success case) --- [Entry Point] [Constants] # {method} {0x0000007f8c6e0308} 'compareAndSetTail' '(Ljava/util/concurrent/locks/AbstractQueuedSynchronizer$Node;Ljava/util/concurrent/locks/AbstractQueuedSynchronizer$Node;)Z' in 'java/util/concurrent/locks/AbstractQueuedSynchronizer' # this: c_rarg1:c_rarg1 = 'java/util/concurrent/locks/AbstractQueuedSynchronizer' # parm0: c_rarg2:c_rarg2 = 'java/util/concurrent/locks/AbstractQueuedSynchronizer$Node' # parm1: c_rarg3:c_rarg3 = 'java/util/concurrent/locks/AbstractQueuedSynchronizer$Node' # [sp+0x20] (sp of caller) ;; N41: # B1 <- BLOCK HEAD IS JUNK Freq: 1 0x0000007f8580a980: ldr w8, [x1,#8] 0x0000007f8580a984: lsl x8, x8, #3 0x0000007f8580a988: cmp x9, x8 0x0000007f8580a98c: b.eq 0x0000007f8580a994 0x0000007f8580a990: b 0x0000007f85147b20 ; {runtime_call} 0x0000007f8580a994: nop [Verified Entry Point] ;; B1: # N41 <- BLOCK HEAD IS JUNK Freq: 1 0x0000007f8580a998: nop 0x0000007f8580a99c: stp x29, x30, [sp,#-16]! 0x0000007f8580a9a0: sub sp, sp, #0x10 ;; membar-release (elided) 0x0000007f8580a9a4: add x10, x1, #0x18 0x0000007f8580a9a8: lsr x12, x3, #3 0x0000007f8580a9ac: mov x11, x10 0x0000007f8580a9b0: lsr x14, x2, #3 0x0000007f8580a9b4: ldaxr w8, [x10] 0x0000007f8580a9b8: cmp w8, w14 0x0000007f8580a9bc: b.ne 0x0000007f8580a9d0 0x0000007f8580a9c0: stlxr w8, w12, [x10] 0x0000007f8580a9c4: cmp w8, wzr 0x0000007f8580a9c8: b.eq 0x0000007f8580a9d0 0x0000007f8580a9cc: b 0x0000007f8580a9b4 0x0000007f8580a9d0: cset x0, eq 0x0000007f8580a9d4: lsr x10, x11, #9 ;; 0x7F8B0F5000 0x0000007f8580a9d8: movz x11, #0x5000 0x0000007f8580a9dc: movk x11, #0x8b0f, lsl #16 0x0000007f8580a9e0: movk x11, #0x7f, lsl #32 0x0000007f8580a9e4: strb wzr, [x11,x10,lsl #0] ;*invokevirtual compareAndSwapObject ; - java.util.concurrent.locks.AbstractQueuedSynchronizer::compareAndSetTail at 9 (line 2294) ;; membar_acquire (elided) 0x0000007f8580a9e8: add sp, sp, #0x10 0x0000007f8580a9ec: ldp x29, x30, [sp],#16 0x0000007f8580a9f0: adrp x8, 0x0000007f9066a000 ; {poll_return} 0x0000007f8580a9f4: ldr wzr, [x8,#256] ; {poll_return} 0x0000007f8580a9f8: ret --- CUT HERE --- From adinn at redhat.com Tue Jan 21 02:57:57 2014 From: adinn at redhat.com (Andrew Dinn) Date: Tue, 21 Jan 2014 10:57:57 +0000 Subject: [aarch64-port-dev ] SPECjvm2008 derby gives SIGBUS with -XX:+TieredCompilation In-Reply-To: <1390300333.19765.40.camel@localhost.localdomain> References: <1389261652.823.9.camel@localhost.localdomain> <1390300333.19765.40.camel@localhost.localdomain> Message-ID: <52DE52B5.9010709@redhat.com> On 21/01/14 10:32, Edward Nevill wrote: How about those stlxr + branch insns: > --- +Tiered compilation (failing case) ---- > . . . > 0x0000007f712e98e8: ldaxr w8, [x0] > 0x0000007f712e98ec: cmp w8, w2 > 0x0000007f712e98f0: cset x8, ne > 0x0000007f712e98f4: b.ne 0x0000007f712e9900 > 0x0000007f712e98f8: stlxr w8, w9, [x0] > 0x0000007f712e98fc: cbnz x8, 0x0000007f712e98e8 > --- -TieredCompilation (success case) --- > . . . > 0x0000007f8580a9b4: ldaxr w8, [x10] > 0x0000007f8580a9b8: cmp w8, w14 > 0x0000007f8580a9bc: b.ne 0x0000007f8580a9d0 > 0x0000007f8580a9c0: stlxr w8, w12, [x10] > 0x0000007f8580a9c4: cmp w8, wzr > 0x0000007f8580a9c8: b.eq 0x0000007f8580a9d0 The first one uses a stlxr which sets w8 and then branches on x8 The second one uses a stlxr which sets w8, compares w8 against zr and then branches on the resulting flag. So, will the first one not suffer a spurious failure when the top half of x8 is non-zero? Whereas the second one will always get the correct result? regards, Andrew Dinn ----------- From aph at redhat.com Tue Jan 21 03:17:10 2014 From: aph at redhat.com (Andrew Haley) Date: Tue, 21 Jan 2014 11:17:10 +0000 Subject: [aarch64-port-dev ] SPECjvm2008 derby gives SIGBUS with -XX:+TieredCompilation In-Reply-To: <52DE52B5.9010709@redhat.com> References: <1389261652.823.9.camel@localhost.localdomain> <1390300333.19765.40.camel@localhost.localdomain> <52DE52B5.9010709@redhat.com> Message-ID: <52DE5736.6000901@redhat.com> On 01/21/2014 10:57 AM, Andrew Dinn wrote: > The second one uses a stlxr which sets w8, compares w8 against zr and > then branches on the resulting flag. So, will the first one not suffer a > spurious failure when the top half of x8 is non-zero? Whereas the second > one will always get the correct result? Could be. It's a trivial fix that should be made. Andrew. From aph at redhat.com Tue Jan 21 03:22:18 2014 From: aph at redhat.com (Andrew Haley) Date: Tue, 21 Jan 2014 11:22:18 +0000 Subject: [aarch64-port-dev ] SPECjvm2008 derby gives SIGBUS with -XX:+TieredCompilation In-Reply-To: <52DE5736.6000901@redhat.com> References: <1389261652.823.9.camel@localhost.localdomain> <1390300333.19765.40.camel@localhost.localdomain> <52DE52B5.9010709@redhat.com> <52DE5736.6000901@redhat.com> Message-ID: <52DE586A.4050909@redhat.com> On 01/21/2014 11:17 AM, Andrew Haley wrote: > On 01/21/2014 10:57 AM, Andrew Dinn wrote: >> The second one uses a stlxr which sets w8, compares w8 against zr and >> then branches on the resulting flag. So, will the first one not suffer a >> spurious failure when the top half of x8 is non-zero? Whereas the second >> one will always get the correct result? > > Could be. It's a trivial fix that should be made. FWIW, I'm pretty sure that the bus error gets triggered by the stack bang. Andrew. From thuhc at yahoo.com Tue Jan 21 18:38:49 2014 From: thuhc at yahoo.com (Cao Hoang Thu) Date: Tue, 21 Jan 2014 18:38:49 -0800 (PST) Subject: [aarch64-port-dev ] SPECjvm2008 hang at startup.compiler.compiler In-Reply-To: <52DE586A.4050909@redhat.com> References: <1389261652.823.9.camel@localhost.localdomain> <1390300333.19765.40.camel@localhost.localdomain> <52DE52B5.9010709@redhat.com> <52DE5736.6000901@redhat.com> <52DE586A.4050909@redhat.com> Message-ID: <1390358329.79247.YahooMailNeo@web164604.mail.gq1.yahoo.com> Hi all, I ran SPECjvm2008 on RTSM with lastest source: #java-Xmx1024m ?-Djava.io.tmpdir=./tmp ?-jar SPECjvm2008.jar -ikv -v But it hang at test-case start.compiler.complier Regards, Thu Cao From thuhc at yahoo.com Tue Jan 21 18:46:50 2014 From: thuhc at yahoo.com (Cao Hoang Thu) Date: Tue, 21 Jan 2014 18:46:50 -0800 (PST) Subject: [aarch64-port-dev ] SPECjvm2008 hang at startup.compiler.sunflow In-Reply-To: <1390358329.79247.YahooMailNeo@web164604.mail.gq1.yahoo.com> References: <1389261652.823.9.camel@localhost.localdomain> <1390300333.19765.40.camel@localhost.localdomain> <52DE52B5.9010709@redhat.com> <52DE5736.6000901@redhat.com> <52DE586A.4050909@redhat.com> <1390358329.79247.YahooMailNeo@web164604.mail.gq1.yahoo.com> Message-ID: <1390358810.70403.YahooMailNeo@web164602.mail.gq1.yahoo.com> Sorry I copy invalid test-case name. SPECjvm2008 hang at test-case?startup.compiler.sunflow Regards, Thu Cao ________________________________ From: Cao Hoang Thu To: "aarch64-port-dev at openjdk.java.net" ; "edward.nevill at linaro.org" Sent: Wednesday, January 22, 2014 9:38 AM Subject: [aarch64-port-dev ] SPECjvm2008 hang at startup.compiler.compiler Hi all, I ran SPECjvm2008 on RTSM with lastest source: #java-Xmx1024m ?-Djava.io.tmpdir=./tmp ?-jar SPECjvm2008.jar -ikv -v But it hang at test-case start.compiler.complier Regards, Thu Cao From edward.nevill at linaro.org Wed Jan 22 01:32:54 2014 From: edward.nevill at linaro.org (Edward Nevill) Date: Wed, 22 Jan 2014 09:32:54 +0000 Subject: [aarch64-port-dev ] SPECjvm2008 hang at startup.compiler.sunflow In-Reply-To: <1390358810.70403.YahooMailNeo@web164602.mail.gq1.yahoo.com> References: <1389261652.823.9.camel@localhost.localdomain> <1390300333.19765.40.camel@localhost.localdomain> <52DE52B5.9010709@redhat.com> <52DE5736.6000901@redhat.com> <52DE586A.4050909@redhat.com> <1390358329.79247.YahooMailNeo@web164604.mail.gq1.yahoo.com> <1390358810.70403.YahooMailNeo@web164602.mail.gq1.yahoo.com> Message-ID: <1390383174.24564.2.camel@localhost.localdomain> Hi Thu Cao, This is a known problem with JDK8. See https://java.net/projects/adoptopenjdk/pages/TestingJava8 (search down the page for SPECJVM2008). I have retested this on x86 trunk and the problem still happens, All the best, Ed. On Tue, 2014-01-21 at 18:46 -0800, Cao Hoang Thu wrote: > Sorry I copy invalid test-case name. SPECjvm2008 hang at > test-case startup.compiler.sunflow > > > Regards, > Thu Cao > > > > ______________________________________________________________________ > From: Cao Hoang Thu > To: "aarch64-port-dev at openjdk.java.net" > ; "edward.nevill at linaro.org" > > Sent: Wednesday, January 22, 2014 9:38 AM > Subject: [aarch64-port-dev ] SPECjvm2008 hang at > startup.compiler.compiler > > > Hi all, > > I ran SPECjvm2008 on RTSM with lastest source: > #java-Xmx1024m -Djava.io.tmpdir=./tmp -jar SPECjvm2008.jar -ikv -v > > > But it hang at test-case start.compiler.complier > > Regards, > Thu Cao > > From thuhc at yahoo.com Wed Jan 22 02:10:44 2014 From: thuhc at yahoo.com (Cao Hoang Thu) Date: Wed, 22 Jan 2014 02:10:44 -0800 (PST) Subject: [aarch64-port-dev ] SPECjvm2008 hang at startup.compiler.sunflow In-Reply-To: <1390383174.24564.2.camel@localhost.localdomain> References: <1389261652.823.9.camel@localhost.localdomain> <1390300333.19765.40.camel@localhost.localdomain> <52DE52B5.9010709@redhat.com> <52DE5736.6000901@redhat.com> <52DE586A.4050909@redhat.com> <1390358329.79247.YahooMailNeo@web164604.mail.gq1.yahoo.com> <1390358810.70403.YahooMailNeo@web164602.mail.gq1.yahoo.com> <1390383174.24564.2.camel@localhost.localdomain> Message-ID: <1390385444.65140.YahooMailNeo@web164603.mail.gq1.yahoo.com> Thanks Ed!!! ________________________________ From: Edward Nevill To: Cao Hoang Thu Cc: "aarch64-port-dev at openjdk.java.net" Sent: Wednesday, January 22, 2014 4:32 PM Subject: Re: [aarch64-port-dev ] SPECjvm2008 hang at startup.compiler.sunflow Hi Thu Cao, This is a known problem with JDK8. See https://java.net/projects/adoptopenjdk/pages/TestingJava8 (search down the page for SPECJVM2008). I have retested this on x86 trunk and the problem still happens, All the best, Ed. On Tue, 2014-01-21 at 18:46 -0800, Cao Hoang Thu wrote: > Sorry I copy invalid test-case name. SPECjvm2008 hang at > test-case startup.compiler.sunflow > > > Regards, > Thu Cao > > > > ______________________________________________________________________ > From: Cao Hoang Thu > To: "aarch64-port-dev at openjdk.java.net" > ; "edward.nevill at linaro.org" > > Sent: Wednesday, January 22, 2014 9:38 AM > Subject: [aarch64-port-dev ] SPECjvm2008 hang at > startup.compiler.compiler > > > Hi all, > > I ran SPECjvm2008 on RTSM with lastest source: > #java-Xmx1024m? -Djava.io.tmpdir=./tmp? -jar SPECjvm2008.jar -ikv -v > > > But it hang at test-case start.compiler.complier > > Regards, > Thu Cao > > From edward.nevill at linaro.org Wed Jan 22 08:40:32 2014 From: edward.nevill at linaro.org (Edward Nevill) Date: Wed, 22 Jan 2014 16:40:32 +0000 Subject: [aarch64-port-dev ] Patch to fix SEGV/SIGBUS in client with +CompressedOops Message-ID: <1390408832.4665.8.camel@localhost.localdomain> Hi, The following patch fixes a problem in the client compiler whereby the cmpval in emit_compare_and_swap was being encoded as a compressed oop while still live. This variously resulted in a SIGBUS or SIGSEGV depending on whether the resultant compressed oop was aligned or not. The patch uses a temp to encode the oop. I have also incorporation a fix to the problem spotted by Andrew Dinn whereby casw did a cbnz rather than a cbnzw on a compressed oop. There is also a minor tweak to use the two arg version of encode_heap_oop(dest, src) instead of the single arg version which removes two redundant moves. OK to push? Ed. --- CUT HERE --- exporting patch: # HG changeset patch # User Edward Nevill edward.nevill at linaro.org # Date 1390408183 0 # Wed Jan 22 16:29:43 2014 +0000 # Node ID 813458fe14eeb9da65e68a12abb85ae1343b2b2d # Parent 895bbf967b692fecdc4919deeb8a30907b5bd2cb - Add fix spotted by Andrew Dinn to do cbnzw instead of cbnz in casw - Use temp reg in emit_compare_and_swap to avoid corrupting cmpval - Minor tweak to use 2 arg vsn of encode_heap_oop diff -r 895bbf967b69 -r 813458fe14ee src/cpu/aarch64/vm/c1_LIRAssembler_aarch64.cpp --- a/src/cpu/aarch64/vm/c1_LIRAssembler_aarch64.cpp Fri Jan 17 13:39:19 2014 -0500 +++ b/src/cpu/aarch64/vm/c1_LIRAssembler_aarch64.cpp Wed Jan 22 16:29:43 2014 +0000 @@ -1584,7 +1584,7 @@ __ stlxrw(rscratch1, newval, addr); // retry so we only ever return after a load fails to compare // ensures we don't return a stale value after a failed write. - __ cbnz(rscratch1, retry_load); + __ cbnzw(rscratch1, retry_load); __ bind(nope); } @@ -1615,10 +1615,12 @@ if (op->code() == lir_cas_obj) { if (UseCompressedOops) { - __ encode_heap_oop(cmpval); - __ mov(rscratch2, newval); + Register t1 = op->tmp1()->as_register(); + assert(op->tmp1()->is_valid(), "must be"); + __ encode_heap_oop(t1, cmpval); + cmpval = t1; + __ encode_heap_oop(rscratch2, newval); newval = rscratch2; - __ encode_heap_oop(newval); casw(addr, newval, cmpval); } else { casl(addr, newval, cmpval); --- CUT HERE --- From aph at redhat.com Wed Jan 22 09:25:24 2014 From: aph at redhat.com (Andrew Haley) Date: Wed, 22 Jan 2014 17:25:24 +0000 Subject: [aarch64-port-dev ] Patch to fix SEGV/SIGBUS in client with +CompressedOops In-Reply-To: <1390408832.4665.8.camel@localhost.localdomain> References: <1390408832.4665.8.camel@localhost.localdomain> Message-ID: <52DFFF04.6080402@redhat.com> On 01/22/2014 04:40 PM, Edward Nevill wrote: > OK to push? Yes, thanks. Andrew. From ed at camswl.com Wed Jan 22 09:29:40 2014 From: ed at camswl.com (ed at camswl.com) Date: Wed, 22 Jan 2014 17:29:40 +0000 Subject: [aarch64-port-dev ] hg: aarch64-port/jdk8/hotspot: - Add fix spotted by Andrew Dinn to do cbnzw instead of cbnz in casw Message-ID: <20140122172952.9BE1D62665@hg.openjdk.java.net> Changeset: 813458fe14ee Author: Edward Nevill edward.nevill at linaro.org Date: 2014-01-22 16:29 +0000 URL: http://hg.openjdk.java.net/aarch64-port/jdk8/hotspot/rev/813458fe14ee - Add fix spotted by Andrew Dinn to do cbnzw instead of cbnz in casw - Use temp reg in emit_compare_and_swap to avoid corrupting cmpval - Minor tweak to use 2 arg vsn of encode_heap_oop ! src/cpu/aarch64/vm/c1_LIRAssembler_aarch64.cpp From edward.nevill at linaro.org Thu Jan 23 01:48:32 2014 From: edward.nevill at linaro.org (Edward Nevill) Date: Thu, 23 Jan 2014 09:48:32 +0000 Subject: [aarch64-port-dev ] RFR: Remove bogus conditionalisation around some SSE code Message-ID: <1390470512.27188.7.camel@localhost.localdomain> Hi, I am seeing the following error in jtreg test compiler/6855215/Test6855215.java # Internal Error (c1_LIRAssembler_aarch64.cpp:149), pid=30625, tid=547389162000 # Error: Unimplemented() Line 149 of c1_LIRAssembler_aarch64.cpp says void LIR_Assembler::ffree(int i) { Unimplemented(); } It is called from the following in c1_LIRAssembler.cpp #if (defined(X86) || defined(AARCH64)) && defined(TIERED) // C2 leave fpu stack dirty clean it if (UseSSE < 2) { int i; for ( i = 1; i <= 7 ; i++ ) { ffree(i); } if (!op->result_opr()->is_float_kind()) { ffree(0); } } #endif // X86 && TIERED This is obviously bogus. Fixed as follows. Regards, Ed. --- CUT HERE --- exporting patch: # HG changeset patch # User Edward Nevill edward.nevill at linaro.org # Date 1390469953 0 # Thu Jan 23 09:39:13 2014 +0000 # Node ID a5eb93bd3d45a88752b784c88047559504d42ba1 # Parent 813458fe14eeb9da65e68a12abb85ae1343b2b2d Remove bogus AARCH64 conditionalisation around some SSE code diff -r 813458fe14ee -r a5eb93bd3d45 src/share/vm/c1/c1_LIRAssembler.cpp --- a/src/share/vm/c1/c1_LIRAssembler.cpp Wed Jan 22 16:29:43 2014 +0000 +++ b/src/share/vm/c1/c1_LIRAssembler.cpp Thu Jan 23 09:39:13 2014 +0000 @@ -495,7 +495,7 @@ compilation()->set_has_method_handle_invokes(true); } -#if (defined(X86) || defined(AARCH64)) && defined(TIERED) +#if defined(X86) && defined(TIERED) // C2 leave fpu stack dirty clean it if (UseSSE < 2) { int i; --- CUT HERE --- From aph at redhat.com Thu Jan 23 08:47:39 2014 From: aph at redhat.com (Andrew Haley) Date: Thu, 23 Jan 2014 16:47:39 +0000 Subject: [aarch64-port-dev ] Fix code that jumps from interpreter to OSR method. Message-ID: <52E147AB.2020005@redhat.com> We've been getting occasional bus errors when compiling. The problem is that the OSR code does not correctly pop the interpreter frame. Two things are wrong: firstly, the stack pointer isn't aligned when it returns, which is the cause of the bus error. Secondly, the nmethod is saved in rmethod (AKA r12) around the call to SharedRuntime::OSR_migration_begin, but r12 is a call-clobbered register. Andrew. # HG changeset patch # User aph # Date 1390495433 18000 # Thu Jan 23 11:43:53 2014 -0500 # Node ID 1e2c91a63fc3019b4958ae443ba66d6862e8e19f # Parent 813458fe14eeb9da65e68a12abb85ae1343b2b2d Fix code that jumps from interpreter to OSR method. diff -r 813458fe14ee -r 1e2c91a63fc3 src/cpu/aarch64/vm/templateTable_aarch64.cpp --- a/src/cpu/aarch64/vm/templateTable_aarch64.cpp Wed Jan 22 16:29:43 2014 +0000 +++ b/src/cpu/aarch64/vm/templateTable_aarch64.cpp Thu Jan 23 11:43:53 2014 -0500 @@ -1759,26 +1759,24 @@ // We need to prepare to execute the OSR method. First we must // migrate the locals and monitors off of the stack. - __ mov(rmethod, r0); // save the nmethod + __ mov(r19, r0); // save the nmethod call_VM(noreg, CAST_FROM_FN_PTR(address, SharedRuntime::OSR_migration_begin)); // r0 is OSR buffer, move it to expected parameter location __ mov(j_rarg0, r0); - // We use j_rarg definitions here so that registers don't conflict as parameter - // registers change across platforms as we are in the midst of a calling - // sequence to the OSR nmethod and we don't want collision. These are NOT parameters. - - // const Register retaddr = j_rarg2; - const Register sender_sp = j_rarg1; - - // pop the interpreter frame - __ ldr(sender_sp, Address(rfp, frame::interpreter_frame_sender_sp_offset * wordSize)); // get sender sp - __ leave(); // remove frame anchor (leaves return address in lr) - __ mov(sp, sender_sp); // set sp to sender sp + // remove activation + // get sender esp + __ ldr(esp, + Address(rfp, frame::interpreter_frame_sender_sp_offset * wordSize)); + // remove frame anchor + __ leave(); + // Ensure compiled code always sees stack at proper alignment + __ andr(sp, esp, -16); + // and begin the OSR nmethod - __ ldr(rscratch1, Address(rmethod, nmethod::osr_entry_point_offset())); + __ ldr(rscratch1, Address(r19, nmethod::osr_entry_point_offset())); __ br(rscratch1); } } From aph at redhat.com Thu Jan 23 08:49:01 2014 From: aph at redhat.com (aph at redhat.com) Date: Thu, 23 Jan 2014 16:49:01 +0000 Subject: [aarch64-port-dev ] hg: aarch64-port/jdk8/hotspot: Fix code that jumps from interpreter to OSR method. Message-ID: <20140123164903.EE1AE626E6@hg.openjdk.java.net> Changeset: 1e2c91a63fc3 Author: aph Date: 2014-01-23 11:43 -0500 URL: http://hg.openjdk.java.net/aarch64-port/jdk8/hotspot/rev/1e2c91a63fc3 Fix code that jumps from interpreter to OSR method. ! src/cpu/aarch64/vm/templateTable_aarch64.cpp From ed at camswl.com Fri Jan 24 02:33:49 2014 From: ed at camswl.com (ed at camswl.com) Date: Fri, 24 Jan 2014 10:33:49 +0000 Subject: [aarch64-port-dev ] hg: aarch64-port/jdk8/hotspot: Remove bogus AARCH64 conditionalisation around some SSE code Message-ID: <20140124103354.846586274A@hg.openjdk.java.net> Changeset: 917f6620f8e3 Author: Edward Nevill edward.nevill at linaro.org Date: 2014-01-24 10:33 +0000 URL: http://hg.openjdk.java.net/aarch64-port/jdk8/hotspot/rev/917f6620f8e3 Remove bogus AARCH64 conditionalisation around some SSE code ! src/share/vm/c1/c1_LIRAssembler.cpp From thuhc at yahoo.com Fri Jan 24 18:32:40 2014 From: thuhc at yahoo.com (Cao Hoang Thu) Date: Fri, 24 Jan 2014 18:32:40 -0800 (PST) Subject: [aarch64-port-dev ] SPECjbb2013 - SIGSEGV In-Reply-To: <1390385444.65140.YahooMailNeo@web164603.mail.gq1.yahoo.com> References: <1389261652.823.9.camel@localhost.localdomain> <1390300333.19765.40.camel@localhost.localdomain> <52DE52B5.9010709@redhat.com> <52DE5736.6000901@redhat.com> <52DE586A.4050909@redhat.com> <1390358329.79247.YahooMailNeo@web164604.mail.gq1.yahoo.com> <1390358810.70403.YahooMailNeo@web164602.mail.gq1.yahoo.com> <1390383174.24564.2.camel@localhost.localdomain> <1390385444.65140.YahooMailNeo@web164603.mail.gq1.yahoo.com> Message-ID: <1390617160.65296.YahooMailNeo@web164602.mail.gq1.yahoo.com> Hi Ed, I used latest source, I ran specjbb2013 with OpenJDK8 C2 on RTSM #java ?-Xms16g -Xmx16g -Xmn8g -jar ./specjbb2013.jar? -m COMPOSITE I got somes SIGSEGV, I didn't complete test-case: # # A fatal error has been detected by the Java Runtime Environment: # # ?SIGSEGV (0xb) at pc=0x0000007f6da36610, pid=6087, tid=541889380880 # # JRE version: OpenJDK Runtime Environment (8.0) (build 1.8.0-internal-thcao_201 4_01_24_09_43-b00) # Java VM: OpenJDK 64-Bit Server VM (25.0-b59 mixed mode linux-aarch64 compresse d oops) # Problematic frame: # J 5048 C2 java.util.concurrent.ForkJoinPool.fullExternalPush(Ljava/util/concur rent/ForkJoinTask;)V (595 bytes) @ 0x0000007f6da36610 [0x0000007f6da36580+0x90] # # Failed to write core dump. Core dumps have been disabled. To enable core dumpi ng, try "ulimit -c unlimited" before starting Java again # # If you would like to submit a bug report, please visit: # ? http://bugreport.sun.com/bugreport/crash.jsp # # # A fatal error has been detected by the Java Runtime Environment: # # ?SIGSEGV (0xb) at pc=0x0000007f999fd28c, pid=6509, tid=542566773264 # # JRE version: OpenJDK Runtime Environment (8.0) (build 1.8.0-internal-thcao_201 4_01_24_09_43-b00) # Java VM: OpenJDK 64-Bit Server VM (25.0-b59 mixed mode linux-aarch64 compresse d oops) # Problematic frame: # J 5294% C2 org.spec.jbb.core.cache.SoftReferenceCache.writeObject(Ljava/io/Obj ectOutputStream;)V (94 bytes) @ 0x0000007f999fd28c [0x0000007f999fce60+0x42c] # # Failed to write core dump. Core dumps have been disabled. To enable core dumpi ng, try "ulimit -c unlimited" before starting Java again # # An error report file with more information is saved as: # /root/SPECjbb2013-1.00/hs_err_pid6509.log # # If you would like to submit a bug report, please visit: # ? http://bugreport.sun.com/bugreport/crash.jsp # Regards, Thu Cao From thuhc at yahoo.com Mon Jan 27 02:03:05 2014 From: thuhc at yahoo.com (Cao Hoang Thu) Date: Mon, 27 Jan 2014 02:03:05 -0800 (PST) Subject: [aarch64-port-dev ] Java <> on RTSM In-Reply-To: <20140122172952.9BE1D62665@hg.openjdk.java.net> References: <20140122172952.9BE1D62665@hg.openjdk.java.net> Message-ID: <1390816985.94036.YahooMailNeo@web164606.mail.gq1.yahoo.com> Hi all, I used java with latest source. I ran java two or three times, it don't exit process and became <> root ? ? 30136 ? ? 1 ?0 Jan22 ? ? ? ? ?00:04:39 [java] root ? ? 30260 ? ? 1 ?0 Jan22 ? ? ? ? ?00:04:49 [java] Example 1: 1) start hadoop 2) run test jobs: teragen and terasort --> you can see defunct process when a job exit 3) stop hadoop --> you can see defunct process Example 2: 1) run SPECjvm2008, SPECjbb2005 two three times --> defunct progress Regards, Thu Cao From aph at redhat.com Mon Jan 27 02:49:01 2014 From: aph at redhat.com (Andrew Haley) Date: Mon, 27 Jan 2014 10:49:01 +0000 Subject: [aarch64-port-dev ] C1: Don't use high parts of registers in arraycopy Message-ID: <52E6399D.9010701@redhat.com> This patch cleans up LIR_Assembler::emit_arraycopy so that it is not affected by garbage in the high parts of 64-bit registers. There was a comment at the start of emit_arraycopy: "length and pos's are all sign extended at this point on 64bit" This comment is not quite right. Let's say a method is deoptimized at a call site. Its outgoing arguments are in registers, as per the Java calling convention. Deoptimization copies these arguments to the stack, as per the interpreter calling convention, but it destroys the upper half of all 32-bit registers. These then get passed to a C1-compiled method, which calls arraycopy, and boom. Andrew. # HG changeset patch # User aph # Date 1390583932 18000 # Fri Jan 24 12:18:52 2014 -0500 # Node ID 1f2d6153f6c1d2cb2c3445808be069159984d968 # Parent 1e2c91a63fc3019b4958ae443ba66d6862e8e19f C1: Don't use high parts of registers in arraycopy. diff -r 1e2c91a63fc3 -r 1f2d6153f6c1 src/cpu/aarch64/vm/c1_LIRAssembler_aarch64.cpp --- a/src/cpu/aarch64/vm/c1_LIRAssembler_aarch64.cpp Thu Jan 23 11:43:53 2014 -0500 +++ b/src/cpu/aarch64/vm/c1_LIRAssembler_aarch64.cpp Fri Jan 24 12:18:52 2014 -0500 @@ -2267,8 +2267,6 @@ Address src_klass_addr = Address(src, oopDesc::klass_offset_in_bytes()); Address dst_klass_addr = Address(dst, oopDesc::klass_offset_in_bytes()); - // length and pos's are all sign extended at this point on 64bit - // test for NULL if (flags & LIR_OpArrayCopy::src_null_check) { __ cbz(src, *stub->entry()); @@ -2287,31 +2285,31 @@ __ br(Assembler::LT, *stub->entry()); } + if (flags & LIR_OpArrayCopy::length_positive_check) { + __ cmpw(length, 0); + __ br(Assembler::LT, *stub->entry()); + } + if (flags & LIR_OpArrayCopy::src_range_check) { - __ lea(tmp, Address(src_pos, length)); + __ addw(tmp, src_pos, length); __ ldrw(rscratch1, src_length_addr); __ cmpw(tmp, rscratch1); __ br(Assembler::HI, *stub->entry()); } if (flags & LIR_OpArrayCopy::dst_range_check) { - __ lea(tmp, Address(dst_pos, length)); + __ addw(tmp, dst_pos, length); __ ldrw(rscratch1, dst_length_addr); __ cmpw(tmp, rscratch1); __ br(Assembler::HI, *stub->entry()); } - if (flags & LIR_OpArrayCopy::length_positive_check) { - __ cmpw(length, 0); - __ br(Assembler::LT, *stub->entry()); - } - // FIXME: The logic in LIRGenerator::arraycopy_helper clears // length_positive_check if the source of our length operand is an // arraylength. However, that arraylength might be zero, and the // stub that we're about to call contains an assertion that count != // 0 . So we make this check purely in order not to trigger an // assertion failure. - __ cbz(length, *stub->continuation()); + __ cbzw(length, *stub->continuation()); if (flags & LIR_OpArrayCopy::type_check) { // We don't know the array types are compatible @@ -2384,15 +2382,13 @@ __ stp(length, src_pos, Address(sp, 2*BytesPerWord)); __ str(src, Address(sp, 4*BytesPerWord)); - __ uxtw(length, length); // FIXME ?? higher 32bits must be null - __ lea(c_rarg0, Address(src, src_pos, Address::uxtw(scale))); __ add(c_rarg0, c_rarg0, arrayOopDesc::base_offset_in_bytes(basic_type)); assert_different_registers(c_rarg0, dst, dst_pos, length); __ lea(c_rarg1, Address(dst, dst_pos, Address::uxtw(scale))); __ add(c_rarg1, c_rarg1, arrayOopDesc::base_offset_in_bytes(basic_type)); assert_different_registers(c_rarg1, dst, length); - __ mov(c_rarg2, length); + __ uxtw(c_rarg2, length); assert_different_registers(c_rarg2, dst); __ load_klass(c_rarg4, dst); @@ -2503,7 +2499,7 @@ __ lea(c_rarg1, Address(dst, dst_pos, Address::uxtw(scale))); __ add(c_rarg1, c_rarg1, arrayOopDesc::base_offset_in_bytes(basic_type)); assert_different_registers(c_rarg1, dst, length); - __ mov(c_rarg2, length); + __ uxtw(c_rarg2, length); assert_different_registers(c_rarg2, dst); bool disjoint = (flags & LIR_OpArrayCopy::overlapping) == 0; From aph at redhat.com Mon Jan 27 02:51:13 2014 From: aph at redhat.com (Andrew Haley) Date: Mon, 27 Jan 2014 10:51:13 +0000 Subject: [aarch64-port-dev ] Floats are not saved as doubles on AArch64 Message-ID: <52E63A21.6090401@redhat.com> Another fix for deoptimization. Without this patch, floats are not correctly saved and restored when deoptimizing at a call site. Andrew. # HG changeset patch # User aph # Date 1390583978 18000 # Fri Jan 24 12:19:38 2014 -0500 # Node ID ac15550877624b9df2ada9b7c653deffd812aed6 # Parent 1f2d6153f6c1d2cb2c3445808be069159984d968 Floats are not saved as doubles on AArch64. diff -r 1f2d6153f6c1 -r ac1555087762 src/cpu/aarch64/vm/c1_Defs_aarch64.hpp --- a/src/cpu/aarch64/vm/c1_Defs_aarch64.hpp Fri Jan 24 12:18:52 2014 -0500 +++ b/src/cpu/aarch64/vm/c1_Defs_aarch64.hpp Fri Jan 24 12:19:38 2014 -0500 @@ -72,9 +72,11 @@ }; -// encoding of float value in debug info: +// Encoding of float value in debug info. This is true on x86 where +// floats are extended to doubles when stored in the stack, false for +// AArch64 where floats and doubles are stored in their native form. enum { - pd_float_saved_as_double = true + pd_float_saved_as_double = false }; #endif // CPU_AARCH64_VM_C1_DEFS_AARCH64_HPP From aph at redhat.com Mon Jan 27 03:25:42 2014 From: aph at redhat.com (aph at redhat.com) Date: Mon, 27 Jan 2014 11:25:42 +0000 Subject: [aarch64-port-dev ] hg: aarch64-port/jdk8/hotspot: 7 new changesets Message-ID: <20140127112619.36B54627BE@hg.openjdk.java.net> Changeset: 1f2d6153f6c1 Author: aph Date: 2014-01-24 12:18 -0500 URL: http://hg.openjdk.java.net/aarch64-port/jdk8/hotspot/rev/1f2d6153f6c1 C1: Don't use high parts of registers in arraycopy. ! src/cpu/aarch64/vm/c1_LIRAssembler_aarch64.cpp Changeset: ac1555087762 Author: aph Date: 2014-01-24 12:19 -0500 URL: http://hg.openjdk.java.net/aarch64-port/jdk8/hotspot/rev/ac1555087762 Floats are not saved as doubles on AArch64. ! src/cpu/aarch64/vm/c1_Defs_aarch64.hpp Changeset: e8ce2c3b62bf Author: aph Date: 2014-01-24 12:23 -0500 URL: http://hg.openjdk.java.net/aarch64-port/jdk8/hotspot/rev/e8ce2c3b62bf Debug code for deoptimization. ! src/share/vm/code/nmethod.hpp ! src/share/vm/runtime/deoptimization.cpp ! src/share/vm/runtime/stackValue.cpp ! src/share/vm/runtime/stackValue.hpp ! src/share/vm/runtime/vframeArray.cpp Changeset: 21a221e4a843 Author: aph Date: 2014-01-24 12:23 -0500 URL: http://hg.openjdk.java.net/aarch64-port/jdk8/hotspot/rev/21a221e4a843 Debug code for fault handling. ! src/os_cpu/linux_aarch64/vm/os_linux_aarch64.cpp Changeset: 724d72ce083b Author: aph Date: 2014-01-24 12:25 -0500 URL: http://hg.openjdk.java.net/aarch64-port/jdk8/hotspot/rev/724d72ce083b Backout 6514 ! src/share/vm/code/nmethod.hpp ! src/share/vm/runtime/deoptimization.cpp ! src/share/vm/runtime/stackValue.cpp ! src/share/vm/runtime/stackValue.hpp ! src/share/vm/runtime/vframeArray.cpp Changeset: 885d42813832 Author: aph Date: 2014-01-25 04:50 -0500 URL: http://hg.openjdk.java.net/aarch64-port/jdk8/hotspot/rev/885d42813832 Backout 6515 ! src/os_cpu/linux_aarch64/vm/os_linux_aarch64.cpp Changeset: 29b33e434551 Author: aph Date: 2014-01-27 11:08 +0000 URL: http://hg.openjdk.java.net/aarch64-port/jdk8/hotspot/rev/29b33e434551 Merge From ed at camswl.com Mon Jan 27 04:40:35 2014 From: ed at camswl.com (Edward Nevill) Date: Mon, 27 Jan 2014 12:40:35 +0000 Subject: [aarch64-port-dev ] Java <> on RTSM In-Reply-To: <1390816985.94036.YahooMailNeo@web164606.mail.gq1.yahoo.com> References: <20140122172952.9BE1D62665@hg.openjdk.java.net> <1390816985.94036.YahooMailNeo@web164606.mail.gq1.yahoo.com> Message-ID: <1390826435.5309.4.camel@mint> Hi Thu Cao, We have found that this was due to the kernel we were using on our RTSM model. We upgraded the kernel and the problem has gone away. Prior to upgrading the kernel we had many defunct processes. Since upgrading we have not seen a single defunct process. All the best, Ed. On Mon, 2014-01-27 at 02:03 -0800, Cao Hoang Thu wrote: > Hi all, > > I used java with latest source. I ran java two or three times, it don't exit process and became <> > > root 30136 1 0 Jan22 ? 00:04:39 [java] > root 30260 1 0 Jan22 ? 00:04:49 [java] > > Example 1: > 1) start hadoop > 2) run test jobs: teragen and terasort > --> you can see defunct process when a job exit > 3) stop hadoop > --> you can see defunct process > > > Example 2: > 1) run SPECjvm2008, SPECjbb2005 two three times --> defunct progress > > Regards, > > Thu Cao From thuhc at yahoo.com Mon Jan 27 05:44:44 2014 From: thuhc at yahoo.com (Cao Hoang Thu) Date: Mon, 27 Jan 2014 05:44:44 -0800 (PST) Subject: [aarch64-port-dev ] Java <> on RTSM In-Reply-To: <1390826435.5309.4.camel@mint> References: <20140122172952.9BE1D62665@hg.openjdk.java.net> <1390816985.94036.YahooMailNeo@web164606.mail.gq1.yahoo.com> <1390826435.5309.4.camel@mint> Message-ID: <1390830284.13593.YahooMailNeo@web164604.mail.gq1.yahoo.com> Hi Ed, What did version kernel you upgrade ? Do you talk about linux kernel ? What can I do to fix this issue ? I need run some test performance on RTSM, but I don't complete because this issue.? Regards, Thu Cao ________________________________ From: Edward Nevill To: Cao Hoang Thu Cc: "aarch64-port-dev at openjdk.java.net" Sent: Monday, January 27, 2014 7:40 PM Subject: Re: [aarch64-port-dev ] Java <> on RTSM Hi Thu Cao, We have found that this was due to the kernel we were using on our RTSM model. We upgraded the kernel and the problem has gone away. Prior to upgrading the kernel we had many defunct processes. Since upgrading we have not seen a single defunct process. All the best, Ed. On Mon, 2014-01-27 at 02:03 -0800, Cao Hoang Thu wrote: > Hi all, > > I used java with latest source. I ran java two or three times, it don't exit process and became <> > > root? ? 30136? ? 1? 0 Jan22 ?? ? ? ? 00:04:39 [java] > root? ? 30260? ? 1? 0 Jan22 ?? ? ? ? 00:04:49 [java] > > Example 1: > 1) start hadoop > 2) run test jobs: teragen and terasort > --> you can see defunct process when a job exit > 3) stop hadoop > --> you can see defunct process > > > Example 2: > 1) run SPECjvm2008, SPECjbb2005 two three times --> defunct progress > > Regards, > > Thu Cao