December 2015 - aarch64-port-dev

VAR_CPU_ARCH for ARM platforms
by Bob Vandette 28 Jan '16

28 Jan '16

In my push to the mobile/dev forest, I changed VAR_CPU_ARCH on arm platforms to always use arm for both 32 and 64 bit arm builds to be consistent with the setting for x86/x86_64. http://cr.openjdk.java.net/~bobv/8145936/webrev.00/ <http://cr.openjdk.java.net/~bobv/8145936/webrev.00/> My assumption which is confirmed by most of the usage in the makefiles is that VAR_CPU_ARCH should be set to the generic ARCH family (x86, arm) for both 32 and 64 bit builds. My motivation for doing this was initially for the selection of the Socket and UnixConstant template files used in cross compilation since these files contain the same content for arm and aarch64. This seems to be causing at least one problem in the hotspot build where in JDK 9, ARCH is being set to VAR_CPU_ARCH (via OPENJDK_TARGET_CPU_ARCH). For aarch64 builds, ARCH gets set to arm. In JDK8, ARCH is set to VAR_CPU and not VAR_CPU_ARCH. Was there a reason for this change? Can we go back to the way it was in JDK8???? There are a lot of hacks in both open and closed makefiles to set various variable based on ARCH in order to end up with the correct variables. In hotspot/make/defs.make, we undo the VAR_CPU_ARCH setting of x86 for x86_64 builds by checking for LP64! This is not done for arm. BUILDARCH ?= $(SRCARCH) ifeq ($(BUILDARCH), x86) ifdef LP64 BUILDARCH = amd64 else BUILDARCH = i486 endif endif in hotspot/make/closed/defs.make, we don't fix this issue either. ifeq ($(ARCH), arm) SRCARCH = arm LIBARCH = arm ARCH_DATA_MODEL = 32 PLATFORM = linux-arm VM_PLATFORM = linux_arm HS_ARCH = arm endif ifeq ($(ARCH), aarch64) BUILDARCH = aarch64 SRCARCH = arm LIBARCH = aarch64 HS_ARCH = arm SAARCH = arm64 endif

5 6

RFR: 8146286: aarch64: guarantee failures with large code cache sizes on jtreg test java/lang/invoke/LFCaching10/LFMultiThreadCachingTest.java
by Edward Nevill 08 Jan '16

08 Jan '16

Hi, The following webrev http://cr.openjdk.java.net/~enevill/8146286/webrev.0/ JIRA Issue: https://bugs.openjdk.java.net/browse/JDK-8146286 The problem is that during code buffer expansion the code buffer can be moved so that a BL is no longer in range. Normally this would resolve to the targets trampoline. However this is inhibited during code buffer expansion because of the following in get_trampoline_for() address trampoline_stub_Relocation::get_trampoline_for(address call, nmethod* code) { // There are no relocations available when the code gets relocated // because of CodeBuffer expansion. if (code->relocation_size() == 0) return NULL; The problem is that the relocs have not been created yet, so get_trampoline_for cannot resolve to the trampoline. The solution I have adopted is to always generate a BL to self in MacroAssembler::trampoline_call. In Relocation::pd_call_destination when it detects a call to self it does not attempt to do the relocation but just leaves it as a call to self (there is no point in trying to relocate the call to self to point to the original destination since that is in the old copy of the code buffer and could be out of range). During final relocation the call to self is then relocated to the correct value. Repeated testing with the above test shows that the problem has been resolved. I have also tested with jtreg hotspot/langtools and jdk, before and after patching and with and without -XX:+ReservedCodeCacheSize=256m with no additional failures. OK to push? Ed.

2 4

guarantee failures with large code cache sizes on jtreg test java/lang/invoke/LFCaching10/LFMultiThreadCachingTest.java
by Edward Nevill 24 Dec '15

24 Dec '15

Hi, I am seeing intermittent guarantee failures on jdk jtreg test java/lang/invoke/LFCaching10/LFMultiThreadCachingTest.jtr. The failure is # # A fatal error has been detected by the Java Runtime Environment: # # Internal Error (assembler_aarch64.hpp:218), pid=43991, tid=44418 # guarantee(chk == -1 || chk == 0) failed: Field too big for insn # The test is being run with -XX:ReservedCodeCacheSize=256m, the following is the full command line /home/ed/images/jdk9-orig/bin/java -XX:-TieredCompilation -jar lib/jtreg.jar -vmoption:-XX:ReservedCodeCacheSize=256m -retain -nr -conc:8 -timeout:99 -othervm -jdk:/home/ed/images/jdk9-orig -v1 -a -ignore:quiet /home/ed/new_jdk9/dev/jdk_test/test/java/lang/invoke I have trapped the failure in gdb, it is occurring in pd_patch_instruction_size when trying to patch a BL instruction. #8 0x000003ff7a7a360c in MacroAssembler::pd_patch_instruction_size ( branch=0x3ff691cf2d8 "\223\323\343\227\277:\003\325\213c\313\071\313\b", target=0x3ff60a108a4 "\375{\277\251\375\003") at /home/ed/new_jdk9/hs-comp/hotspot/src/cpu/aarch64/vm/macroAssembler_aarch64.cpp:74 74 Instruction_aarch64::spatch(branch, 25, 0, offset); (gdb) p offset $17 = -35584653 (gdb) Here is the backtrace from gdb #8 0x000003ff7a7a360c in MacroAssembler::pd_patch_instruction_size ( branch=0x3ff691cf2d8 "\223\323\343\227\277:\003\325\213c\313\071\313\b", target=0x3ff60a108a4 "\375{\277\251\375\003") at /home/ed/new_jdk9/hs-comp/hotspot/src/cpu/aarch64/vm/macroAssembler_aarch64.cpp:74 #9 0x000003ff7a33451c in MacroAssembler::pd_patch_instruction ( branch=0x3ff691cf2d8 "\223\323\343\227\277:\003\325\213c\313\071\313\b", target=0x3ff60a108a4 "\375{\277\251\375\003") at /home/ed/new_jdk9/hs-comp/hotspot/src/cpu/aarch64/vm/macroAssembler_aarch64.hpp:565 #10 0x000003ff7a8ca9bc in Relocation::pd_set_call_destination (this=0x3fdc5fab3e8, x=0x3ff60a108a4 "\375{\277\251\375\003") at /home/ed/new_jdk9/hs-comp/hotspot/src/cpu/aarch64/vm/relocInfo_aarch64.cpp:85 #11 0x000003ff7a8c8650 in CallRelocation::fix_relocation_after_move ( this=0x3fdc5fab3e8, src=0x3fdc5fae0b0, dest=0x3fdc5fab490) at /home/ed/new_jdk9/hs-comp/hotspot/src/share/vm/code/relocInfo.cpp:549 #12 0x000003ff7a4736bc in CodeBuffer::relocate_code_to (this=0x3fdc5fae0b0, dest=0x3fdc5fab490) at /home/ed/new_jdk9/hs-comp/hotspot/src/share/vm/asm/codeBuffer.cpp:812 #13 0x000003ff7a473be8 in CodeBuffer::expand (this=0x3fdc5fae0b0, which_cs=0x3fdc5fae158, amount=64) at /home/ed/new_jdk9/hs-comp/hotspot/src/share/vm/asm/codeBuffer.cpp:942 #14 0x000003ff7a334404 in CodeSection::maybe_expand_to_ensure_remaining ( this=0x3fdc5fae158, amount=64) at /home/ed/new_jdk9/hs-comp/hotspot/src/share/vm/asm/codeBuffer.hpp:661 #15 0x000003ff7a33379c in AbstractAssembler::start_a_stub (this=0x3fdc5fab838, required_space=64) at /home/ed/new_jdk9/hs-comp/hotspot/src/share/vm/asm/assembler.cpp:65 #16 0x000003ff7a7a54a0 in MacroAssembler::emit_trampoline_stub (this=0x3fdc5fab838, insts_call_instruction_offset=976, dest=0x3ff609cf080 "\375{\277\251H\001") at /home/ed/new_jdk9/hs-comp/hotspot/src/cpu/aarch64/vm/macroAssembler_aarch64.cpp:704 #17 0x000003ff7a7a53c0 in MacroAssembler::trampoline_call (this=0x3fdc5fab838, entry=..., cbuf=0x3fdc5fae0b0) at /home/ed/new_jdk9/hs-comp/hotspot/src/cpu/aarch64/vm/macroAssembler_aarch64.cpp:673 #18 0x000003ff7a2a1bd0 in CallStaticJavaDirectNode::emit (this=0x3fdac0024b0, cbuf=..., ra_=0x3fdc5fabd30) at /home/ed/new_jdk9/hs-comp/hotspot/src/cpu/aarch64/vm/aarch64.ad:4673 #19 0x000003ff7a85edc0 in Compile::fill_buffer (this=0x3fdc5fad870, cb=0x3fdc5fae0b0, blk_starts=0x3fd40042520) at /home/ed/new_jdk9/hs-comp/hotspot/src/share/vm/opto/output.cpp:1380 #20 0x000003ff7a85b960 in Compile::Output (this=0x3fdc5fad870) at /home/ed/new_jdk9/hs-comp/hotspot/src/share/vm/opto/output.cpp:154 #21 0x000003ff7a4a6c88 in Compile::Code_Gen (this=0x3fdc5fad870) at /home/ed/new_jdk9/hs-comp/hotspot/src/share/vm/opto/compile.cpp:2407 #22 0x000003ff7a4a1fa8 in Compile::Compile (this=0x3fdc5fad870, ci_env=0x3fdc5fae390, compiler=0x3ff746bc7d0, target=0x3fd981ff670, osr_bci=-1, subsume_loads=true, do_escape_analysis=true, eliminate_boxing=true, directive=0x3ff74680570) at /home/ed/new_jdk9/hs-comp/hotspot/src/share/vm/opto/compile.cpp:899 #23 0x000003ff7a3e7684 in C2Compiler::compile_method (this=0x3ff746bc7d0, env=0x3fdc5fae390, target=0x3fd981ff670, entry_bci=-1, directive=0x3ff74680570) at /home/ed/new_jdk9/hs-comp/hotspot/src/share/vm/opto/c2compiler.cpp:106 #24 0x000003ff7a4b2ea8 in CompileBroker::invoke_compiler_on_method ( task=0x3fd640bbfd0) at /home/ed/new_jdk9/hs-comp/hotspot/src/share/vm/compiler/compileBroker.cpp:1814 #25 0x000003ff7a4b25d4 in CompileBroker::compiler_thread_loop () at /home/ed/new_jdk9/hs-comp/hotspot/src/share/vm/compiler/compileBroker.cpp:1564 #26 0x000003ff7a96a9b4 in compiler_thread_entry (thread=0x3ff746bf000, __the_thread__=0x3ff746bf000) at /home/ed/new_jdk9/hs-comp/hotspot/src/share/vm/runtime/thread.cpp:3238 #27 0x000003ff7a9678f4 in JavaThread::thread_main_inner (this=0x3ff746bf000) at /home/ed/new_jdk9/hs-comp/hotspot/src/share/vm/runtime/thread.cpp:1723 #28 0x000003ff7a967830 in JavaThread::run (this=0x3ff746bf000) at /home/ed/new_jdk9/hs-comp/hotspot/src/share/vm/runtime/thread.cpp:1703 #29 0x000003ff7a849614 in java_start (thread=0x3ff746bf000) at /home/ed/new_jdk9/hs-comp/hotspot/src/os/linux/vm/os_linux.cpp:683 #30 0x000003ff7af07e2c in start_thread (arg=0x3fdc5faf1f0) at pthread_create.c:314 #31 0x000003ff7ae18c40 in clone () at ../ports/sysdeps/unix/sysv/linux/aarch64/nptl/../clone.S:96 Looking at frame #11 above we see (gdb) list 544 // On some platforms, the reference is absolute (not self-relative). 545 // The enhanced use of pd_call_destination sorts this all out. 546 address orig_addr = old_addr_for(addr(), src, dest); 547 address callee = pd_call_destination(orig_addr); 548 // Reassert the callee address, this time in the new copy of the code. 549 pd_set_call_destination(callee); 550 } 551 552 553 //// pack/unpack methods (gdb) p/x addr() $18 = 0x3ff691cf2d8 (gdb) p/x orig_addr $19 = 0x3ff6111ba58 (gdb) p/x callee $20 = 0x3ff60a108a4 Looking at a section of code at both orig_addr and addr() and at the destination of the BL in each case we have (gdb) x/10i orig_addr-20 0x3ff6111ba44: add x10, x14, w15, sxtw 0x3ff6111ba48: sxtw x2, w17 0x3ff6111ba4c: add x0, x10, #0x10 0x3ff6111ba50: cmp w17, w13 0x3ff6111ba54: b.lt 0x3ff6111bb24 0x3ff6111ba58: bl 0x3ff60a108a4 0x3ff6111ba5c: dmb ishst 0x3ff6111ba60: ldrsb w11, [x28,#728] 0x3ff6111ba64: cbnz w11, 0x3ff6111bb7c 0x3ff6111ba68: mov x10, x19 (gdb) x/10i 0x3ff60a108a4 0x3ff60a108a4: stp x29, x30, [sp,#-16]! 0x3ff60a108a8: mov x29, sp 0x3ff60a108ac: cmp x1, x0 0x3ff60a108b0: b.ls 0x3ff60a10808 0x3ff60a108b4: add x0, x0, x2, uxtx 0x3ff60a108b8: add x1, x1, x2, uxtx 0x3ff60a108bc: cmp x2, #0x10 0x3ff60a108c0: b.cc 0x3ff60a10914 0x3ff60a108c4: and x9, x0, #0xf 0x3ff60a108c8: cbz x9, 0x3ff60a1090c (gdb) x/10i addr()-20 0x3ff691cf2c4: add x10, x14, w15, sxtw 0x3ff691cf2c8: sxtw x2, w17 0x3ff691cf2cc: add x0, x10, #0x10 0x3ff691cf2d0: cmp w17, w13 0x3ff691cf2d4: b.lt 0x3ff691cf3a4 0x3ff691cf2d8: bl 0x3ff68ac4124 0x3ff691cf2dc: dmb ishst 0x3ff691cf2e0: ldrsb w11, [x28,#728] 0x3ff691cf2e4: cbnz w11, 0x3ff691cf3fc 0x3ff691cf2e8: mov x10, x19 (gdb) x/10i 0x3ff68ac4124 0x3ff68ac4124: .inst 0x00000000 ; undefined 0x3ff68ac4128: .inst 0x00000000 ; undefined 0x3ff68ac412c: .inst 0x00000000 ; undefined 0x3ff68ac4130: .inst 0x00000000 ; undefined 0x3ff68ac4134: .inst 0x00000000 ; undefined 0x3ff68ac4138: .inst 0x00000000 ; undefined 0x3ff68ac413c: .inst 0x00000000 ; undefined 0x3ff68ac4140: .inst 0x00000000 ; undefined 0x3ff68ac4144: .inst 0x00000000 ; undefined 0x3ff68ac4148: .inst 0x00000000 ; undefined What appears to be the case here is that we have a BL to another method, therefore outside the scope of the current codeblob. However, this codeblob is now being moved and will now require a trampoline instead of a straight BL. However the BL is not recognised as requiring a trampoline. Looking at frame #10 (gdb) down #10 0x000003ff7a8ca9bc in Relocation::pd_set_call_destination (this=0x3fdc5fab3e8, x=0x3ff60a108a4 "\375{\277\251\375\003") at /home/ed/new_jdk9/hs-comp/hotspot/src/cpu/aarch64/vm/relocInfo_aarch64.cpp:85 85 MacroAssembler::pd_patch_instruction(addr(), x); (gdb) list 81 76 assert(is_call(), "should be a call here"); 77 if (NativeCall::is_call_at(addr())) { 78 address trampoline = nativeCall_at(addr())->get_trampoline(); 79 if (trampoline) { 80 nativeCall_at(addr())->set_destination_mt_safe(x, /* assert_lock */false); 81 return; 82 } 83 } 84 assert(addr() != x, "call instruction in an infinite loop"); 85 MacroAssembler::pd_patch_instruction(addr(), x); 'trampoline' is set to false here (gdb) p NativeCall::is_call_at(addr()) $21 = true (gdb) p nativeCall_at(addr())->get_trampoline() $22 = (u_char *) 0x0 (gdb) Looking at the source for get_trampoline() CodeBlob *code = CodeCache::find_blob(call_addr); assert(code != NULL, "Could not find the containing code blob"); address bl_destination = MacroAssembler::pd_call_destination(call_addr); if (code->content_contains(bl_destination) && is_NativeCallTrampolineStub_at(bl_destination)) return bl_destination; This only tests for a trampoline if the BL destination is within the current code blob, and as seen previously with the problems with adrp, it must not test for a trampoline outside the current code blob because that could be pointing somewhere completely random. In this case it happens to be pointing to a block of .inst 0x00000000 words. The problem arises from the implementation of MacroAssembler::trampoline_call where is does if (Assembler::reachable_from_branch_at(pc(), entry.target())) { bl(entry.target()); } else { bl(pc()); } Here if the call reaches, it plants a BL, however when the call subsequently fails to reach, because the codeblob is moved out of range of a bl, it has no way of finding the trampoline, because it will not look outside the current code blob. Only possibility might be to always write it as bl(pc()) and rely on the final reloc to fix it up to either point to the trampoline, or call direct. However I think there may be a problem with this if the codeblob is moved more than once, in this case the first move would relocate it using a direct BL and then the second could move it out of range and fail to find the trampoline as above. Anyone got any ideas on how to fix this? All the best, and Happy Christmas, Ed.

2 1

RFR: 8144993: Elide redundant memory barrier after AllocationNode
by Hui Shi 18 Dec '15

18 Dec '15

Hi All, Could some one help comments this change? Bug: https://bugs.openjdk.java.net/browse/JDK-8144993 webrev: http://cr.openjdk.java.net/~hshi/8144993/webrev/ This patch aims to remove redundant memory barrier after allocation node, on AArch64 it removes redundant dmb when creating object. The motivation is dmb instructions after commonly used object allocation, for example string and boxing objects is redundant with dmb inserted for final field write. In following small case: String foo(String s) { String copy = new String(s); return copy; } There are two dmb instructions in generated code. First one is membar_storestore, inserted in PhaseMacroExpand::expand_allocate_common. Second one is membar_release, inserted at exit of initializer method as final fields write happens. Allocated String doesn't escape in String initializer method, membar_release includes membar_storestore semantic. So first one can be removed safely. 0x0000007f85bbfa8c: prfm pstl1keep, [x11,#256] 0x0000007f85bbfa90: str xzr, [x0,#16] 0x0000007f85bbfa94: dmb ishst // first dmb to remove .... 0x0000007fa01d83c0: ldrsb w10, [x20,#20] 0x0000007fa01d83c4: ldr w12, [x20,#16] 0x0000007fa01d83c8: ldr x11, [sp,#8] 0x0000007fa01d83cc: strb w10, [x11,#20] 0x0000007fa01d83d0: str w12, [x11,#16] 0x0000007fa01d83d4: dmb ish // second dmb Patch targets this pattern and remove redundant memory barrier for allocation node. 1. When inserting memory barrier for final field write. If final fields' object allocation node is available, invoke AllocationNode::compute_MemBar_redundancy(initializer method). 2. In AllocationNode: 2.1 Add a new field _is_allocation_MemBar_redundant flag indicate if memory barrier after allocation node is redundant. 2.2 Add method compute_MemBar_redundancy, set _is_allocation_MemBar_redundant true if first parameter "this" does not escape in initializer method according to BCEscapeAnalyzer. 3. skip inserting memory barrier in PhaseMacroExpand::expand_allocate_common, when AllocationNode's _is_allocation_MemBar_redundant flag is true. Regards Hui

7 35

RFR: JDK 7: Add Support for Large Code Cache on aarch64
by Edward Nevill 17 Dec '15

17 Dec '15

Hi, The following webrev adds support for large code caches to JDK 7 for aarch64 http://cr.openjdk.java.net/~enevill/jdk7_largecode/webrev/ Tested with jtreg hotspot/langtools. hotspot (original): Test results: passed: 297; failed: 12; error: 2 hotspot (patched): Test results: passed: 297; failed: 12; error: 2 hotspot (256m cache): Test results: passed: 298; failed: 11; error: 2 langtools (original): Test results: passed: 1,973; failed: 1 langtools (patched): Test results: passed: 1,973; failed: 1 langtools (256m cache): Test results: passed: 1,973; failed: 1 Only aarch64 files are touched in this patch. OK to push? Ed.

1 0

RFR: 8144498: aarch64: large code cache generates SEGV
by Edward Nevill 15 Dec '15

15 Dec '15

Hi, Please review the following webrev http://cr.openjdk.java.net/~enevill/8144498/webrev.0/ JIRA issue: https://bugs.openjdk.java.net/browse/JDK-8144498 This fixes an issue when random SEGVs were generated with -XX:ReservedCodeCacheSize > 128m The problem was that pd_call_destination was using addr() rather than orig_addr. IE. It was using the address in the copied, but not relocated code. It was then following a call destination to determine whether or not this was a call to a trampoline (in order that it could substitute the final trampoline address). Usually this worked OK because it ended up just referencing a random address in the code buffer. However, very occasionally it would point to a trampoline somewhere in the code buffer and get a false positive. In this case it would substitute the final address of that trampoline. The result was that it would very occasionally relocate the address of some call to a random trampoline stub. I have tested this with jtreg hotspot and langtools with -XX:ReservedCodeCacheSize=256m and without specifying any ReservedCodeCacheSize (so it defaults to 128m). With ReservedCodeCacheSize == default Hotspot (original): Test results: passed: 935; failed: 22; error: 12 Hotspot (patched): Test results: passed: 942; failed: 15; error: 12 Langtools (original): Test results: passed: 3,313; failed: 33 Langtools (patched): Test results: passed: 3,316; failed: 33 With -XX:+ReservedCodeCacheSize=256m Hotspot (original): Test results: passed: 865; failed: 19; error: 85 Hotspot (patched): Test results: passed: 946; failed: 10; error: 13 Langtools (original): Test results: passed: 3,049; failed: 77; error: 223 Langtools (patched): Test results: passed: 3,314; failed: 33 So in all cases it generates results as good, or better than the original. In the case of langtools with a 256m buffer it goes from 300 failures+errors to just 33. I have also tested this with EEMBC GrinderBench which also showed the problem every few 100 runs. I have run this over 5000 times with no occurrence of the problem. Thanks for your review, Ed.

3 9

RFR: 8145320: Create unsafe_arraycopy and generic_arraycopy for AArch64
by Andrew Haley 14 Dec '15

14 Dec '15

http://cr.openjdk.java.net/~aph/8145320-1/ Andrew.

2 1

RFR: aarch64: backports to JDK 7
by Edward Nevill 14 Dec '15

14 Dec '15

Hi, Please review the following backports to JDK 7 http://cr.openjdk.java.net/~enevill/jdk7_backports_1511/ Tested with jtreg hotspot & langtools. Results the same before and after. Hotspot: Test results: passed: 297; failed: 12; error: 2 Langtools: Test results: passed: 1,971; failed: 1; error: 2 Summary of the changesets below. Thanks, Ed. --- enevill@arm64:~/icedtea7-forest/hotspot$ hg outgoing comparing with ssh://enevill@icedtea.classpath.org/hg/icedtea7-forest/hotspot running ssh enevill(a)icedtea.classpath.org 'hg -R hg/icedtea7-forest/hotspot serve --stdio' searching for changes changeset: 6380:5b6efbae9fea user: aph date: Wed Nov 04 13:38:38 2015 +0100 files: src/share/vm/gc_implementation/parallelScavenge/psParallelCompact.hpp description: 8138966: Intermittent SEGV running ParallelGC Summary: Add necessary memory fences so that the parallel threads are unable to observe partially filled block tables. Reviewed-by: tschatzl changeset: 6381:c7679d143590 user: enevill date: Thu Nov 19 15:15:20 2015 +0000 files: src/cpu/aarch64/vm/assembler_aarch64.cpp description: 8143067: aarch64: guarantee failure in javac Summary: Fix adrp going out of range during code relocation Reviewed-by: aph, kvn changeset: 6382:eeb4a3ec4563 tag: tip user: hshi date: Tue Nov 24 09:02:26 2015 +0000 files: src/cpu/aarch64/vm/interp_masm_aarch64.cpp description: 8143285: aarch64: Missing load acquire when checking if ConstantPoolCacheEntry is resolved Reviewed-by: roland, aph ---

2 2

hg: aarch64-port/jdk8/hotspot: 2 new changesets
by edward.nevill＠gmail.com 14 Dec '15

14 Dec '15

Changeset: b2df86902f5e Author: enevill Date: 2015-12-09 13:08 +0000 URL: http://hg.openjdk.java.net/aarch64-port/jdk8/hotspot/rev/b2df86902f5e Add support for large code cache ! src/cpu/aarch64/vm/aarch64.ad ! src/cpu/aarch64/vm/assembler_aarch64.cpp ! src/cpu/aarch64/vm/assembler_aarch64.hpp ! src/cpu/aarch64/vm/c1_CodeStubs_aarch64.cpp ! src/cpu/aarch64/vm/c1_LIRAssembler_aarch64.cpp ! src/cpu/aarch64/vm/c1_LIRAssembler_aarch64.hpp ! src/cpu/aarch64/vm/c1_MacroAssembler_aarch64.cpp ! src/cpu/aarch64/vm/c1_Runtime1_aarch64.cpp ! src/cpu/aarch64/vm/compiledIC_aarch64.cpp ! src/cpu/aarch64/vm/globalDefinitions_aarch64.hpp ! src/cpu/aarch64/vm/globals_aarch64.hpp ! src/cpu/aarch64/vm/icBuffer_aarch64.cpp ! src/cpu/aarch64/vm/macroAssembler_aarch64.cpp ! src/cpu/aarch64/vm/macroAssembler_aarch64.hpp ! src/cpu/aarch64/vm/methodHandles_aarch64.cpp ! src/cpu/aarch64/vm/nativeInst_aarch64.cpp ! src/cpu/aarch64/vm/nativeInst_aarch64.hpp ! src/cpu/aarch64/vm/relocInfo_aarch64.cpp ! src/cpu/aarch64/vm/sharedRuntime_aarch64.cpp ! src/cpu/aarch64/vm/stubGenerator_aarch64.cpp ! src/cpu/aarch64/vm/templateInterpreter_aarch64.cpp ! src/cpu/aarch64/vm/vtableStubs_aarch64.cpp ! src/os_cpu/linux_aarch64/vm/os_linux_aarch64.cpp ! src/share/vm/runtime/arguments.cpp ! src/share/vm/utilities/globalDefinitions.hpp Changeset: 0096f1ef564e Author: aph Date: 2015-09-15 16:14 +0000 URL: http://hg.openjdk.java.net/aarch64-port/jdk8/hotspot/rev/0096f1ef564e Remove AArch64-specific code in generateOptoStub.cpp. In aarch64_enc_java_to_runtime leave a breadcrumb for JavaThread::pd_last_frame(). ! src/cpu/aarch64/vm/aarch64.ad ! src/share/vm/opto/generateOptoStub.cpp

1 0

Guarantee failures since 8144028: Use AArch64 bit-test instructions in C2
by Edward Nevill 10 Dec '15

10 Dec '15

Hi, Since "8144028: Use AArch64 bit-test instructions in C2" I have been seeing occasional guarantee failures of the form. # Internal Error (assembler_aarch64.hpp:223), pid=4241, tid=4595 # guarantee(chk == -1 || chk == 0) failed: Field too big for insn These are being generated by the following call from pd_patch_instruction_size in macroAssembler_aarch64.cpp // Test & branch (immediate) Instruction_aarch64::spatch(branch, 18, 5, offset); The problem is that test and branch instructions only have a 14 bit offset giving a range of +/- 32Kb which is not sufficient for large C2 methods. What can we do about this? It seems a shame to backout this optimization but I cannot see any easy way around it. All the best, Ed.

2 6