August 2015 - aarch64-port-dev

Support large codecache for JDK8
by Andrew Dinn 26 Nov '15

26 Nov '15

Attached for review is a patch which adds large codecache support to jdk8 (jdk7 version will be next). It passes basic smoke tests (java hello, javac Hello.java, netbeans build and run simple project). Ok to push? regards, Andrew Dinn -----------

3 7

RFR: Disable C2 peephole by default for aarch64
by Felix Yang 30 Sep '15

30 Sep '15

Hi JIT members, Currently, the C2 peephole optimization is only enabled by default for x86 & aarch64 port. But we don't have any peephole rules for aarch64 port, scanning the instruction stream in PhasePeephole::do_transform does not make sense but a waste of time for this port. So I am disabling this pass for aarch64 port by default, can anyone sponsor this if approved? PATCH: diff -r a6acc533dfef src/cpu/aarch64/vm/c2_globals_aarch64.hpp --- a/src/cpu/aarch64/vm/c2_globals_aarch64.hpp Wed Aug 19 16:16:54 2015 +0100 +++ b/src/cpu/aarch64/vm/c2_globals_aarch64.hpp Fri Aug 28 09:28:07 2015 +0800 @@ -69,7 +69,7 @@ // Peephole and CISC spilling both break the graph, and so makes the // scheduler sick. -define_pd_global(bool, OptoPeephole, true); +define_pd_global(bool, OptoPeephole, false); define_pd_global(bool, UseCISCSpill, true); define_pd_global(bool, OptoScheduling, false); define_pd_global(bool, OptoBundling, false);

3 3

RFR: 8080293: AARCH64: Remove unnecessary dmbs from generated CAS code
by Andrew Dinn 17 Sep '15

17 Sep '15

The following webrev against hs-comp head fixes 8080293 http://cr.openjdk.java.net/~adinn/8080293/webrev.00/ It is a follow on to the prior volatile object patch 8078743: AARCH64: Extend use of stlr to cater for volatile object stores http://cr.openjdk.java.net/~adinn/8078743/webrev.04/ and requires that previous patch to be applied first. Testing ------- The patch is sensitive to GC configuration so it was tested against 5 relevant configs G1 CMS+UseCondCardMark CMS-UseCondCardMark Par+UseCondCardMark Par-UseCondCardMark The validity of the transformation was verified by: generating and eyeballing compiled code for simple test programs successfully running a fairly large program (netbeans) generating and eyeballing HashMap code compiled on a fairly large program run The fix was performance tested on 2 implementations of the AArch64 architecture (more details below). On an O-O-O CPU it gave no noticeable benefit. On a simple pipeline CPU it gave a very significant benefit in specific cases. regards, Andrew Dinn ----------- Senior Principal Software Engineer Red Hat UK Ltd Registered in UK and Wales under Company Registration No. 3798903 Directors: Michael Cunningham (USA), Matt Parson (USA), Charlie Peters (USA), Michael O'Neill (Ireland) The Test -------- As with the prior patch I tested the original vs new code generation strategy by running a jmh test first with -XX:+UseBarriersForVolatile and then with -XX:+UseBarriersForVolatile. Four different test programs ran in all 5 GC configs executing. Each test executed repeated CAS operations to an object field in a single thread with a BlackHole backoff between CASes varying from 0 to 64. Test one performed a CAS guaranteed to fail; test two performed a successful CAS from a fixed object to null and then back; test three performed a successful CAS from a fixed object to another fixed object and then back; test four performed a successful CAS from a fixed object to a newly allocated object and then back. The average time per CAS operation (ns/op) -- actually per 2 CAS operations for the latter 3 tests -- was used as a score. The Results ----------- On an O-O-O CPU there was no significant difference in the time taken. On a simple pipeline CPU the optimization gave a very significant benefit for the Fail tests on all GC configurations except CMS + UseCondCardMark. In all other cases there was no significant measurable benefit. Example Test ------------ package org.openjdk; import org.openjdk.jmh.annotations.*; import org.openjdk.jmh.infra.Blackhole; import java.util.concurrent.TimeUnit; import java.util.concurrent.atomic.AtomicReference; @Warmup(iterations = 10, time = 1, timeUnit = TimeUnit.SECONDS) @Measurement(iterations = 5, time = 1, timeUnit = TimeUnit.SECONDS) @Fork(3) @BenchmarkMode(Mode.AverageTime) @OutputTimeUnit(TimeUnit.NANOSECONDS) @State(Scope.Benchmark) public class CasNull { Object tombstone; AtomicReference<Object> ref; @Param({"0", "1", "2", "4", "8", "16", "32", "64"}) int backoff; @Setup public void setup() { tombstone = new Object(); ref = new AtomicReference<>(); ref.set(tombstone); } @Benchmark public boolean test() { Blackhole.consumeCPU(backoff); ref.compareAndSet(tombstone, null); ref.compareAndSet(null, tombstone); return true; } }

4 12

Re: [aarch64-port-dev ] aarch64: C2 fast lock/unlock issues
by Vladimir Kozlov 29 Aug '15

29 Aug '15

Thank you for report and suggested fixes. CC to aarch64 port developers. Thanks, Vladimir On 8/21/15 5:21 AM, Hui Shi wrote: > Hi JIT members, > Attached fast_lock.patch fixes issues in fast lock/unlock on aarch64 > platform (in both aarch64-jdk8 and jdk9/hs-comp/hotspot). Could someone > help comments, review or sponsor? > A small test case and PrintAssembly log with/without fix are also > attached for reference. > > To reproduce this issue on aarch64, command line is "java > -XX:-TieredCompilation -XX:+UnlockDiagnosticVMOptions > -XX:-BackgroundCompilation -XX:CompileCommand="compileonly,TestSync.f*" > -XX:+PrintAssembly TestSync" > There are three Issues in aarch64 fast lock/unlock: > *1. Duplicated biased lock checking* > When option UseBiasedLocking and UseOptoBiasInlining are both true, it > doesn't need emit biased_locking_enter in aarch64_enc_fast_lock. This is > redundant as biased locking enter check is already inlined in > PhaseMacroExpand::expand_lock_node. Checking assembly code in orig.asm > > [Inlined biased lock check in PhaseMacroExpand::expand_lock_node] > 0x000003ff88320d94: str x1, [sp] > 0x000003ff88320d98: ldr x10, [x1] > 0x000003ff88320d9c: and x11, x10, #0x7 > 0x000003ff88320da0: cmp x11, #0x5 > 0x000003ff88320da4: b.ne <http://b.ne> 0x000003ff88320e18 > [Biased lock check expanded in aarch64_enc_fast_lock] > 0x000003ff88320e18: add x12, sp, #0x10 > 0x000003ff88320e1c: ldr x10, [x1] > 0x000003ff88320e20: and x11, x12, #0x7 > 0x000003ff88320e24: cmp x11, #0x5 > 0x000003ff88320e28: b.ne <http://b.ne> 0x000003ff88320eec > *2. Incorrect parameter used in biased_locking_enter in > aarch64_enc_fast_lock* > Checking above code [Biased lock check expanded in > aarch64_enc_fast_lock], x12 is the box register and holding the address > of the lock record on stack. However it is mis-used as mark word in > biased lock checking here. As a result, biased pattern check always > fails because stack pointer is 8 bytes align and x11 must be zero. > Current implementation in aarch64_enc_fast_lock. > /biased_locking_enter(disp_hdr, oop, box, tmp, true, cont);/ > Which should be > /biased_locking_enter(box, oop, disp_hdr, tmp, true, cont); //swap > disp_hdr and box register, disp_hdr is already loaded with object mark word/ > This issue might cause problem when running with option > -XX:-UseOptoBiasInlining in following scenario, let’s check above code > in [Biased lock check expanded in aarch64_enc_fast_lock], x12 is box and > x10 is disp_hdr. > 1. Suppose object’s mark word (loaded into register x10) is in biased > mode, with content “[biased_thread |epoch|age| 101]” and biased_thread > is executing its synchronized block. > 2. Another thread tries to acquire the same lock. Firstly, it performs > biased pattern check and fails, because “mark word” register used here > is X12 (correct register should be x10). > 3. As x12 is not “biased” (least three significant bits of SP + 0x10 > would never be 101), execution goes to thin lock CAS acquire code > instead of biased lock revoke/rebias code. > 4. Thin lock CAS acquire will succeed because x10’s least two > significant bit is 01 (thin lock CAS code uses disp_hdr (x10) as mark > word). Two threads acquire same lock at same time and this is incorrect > behavior. > > *3. Inflate monitor code has typo in aarch64_enc_fast_lock* > Inflated lock test is generated under condition (EmitSync & 0x02), while > generating inflated lock fast path under condition "if ((EmitSync & > 0x02) == 0))". At both location, they should be "if ((EmitSync & 0x02) > == 0) ". In orig.asm, no instruction branches to inflated lock acquire > fast path at 0x000003ff88320f24. > Issue #1 and #3 does not impact correctness, they introduce redundant > code (double biased lock check) and skip inflated lock fast path check > (_owner is null case). > Fix is in aarch64_enc_fast_lock/aarch64_enc_fast_unlock, this will not > impact C1 and interpreter. Attached patch includes: > 1. Disable generating biased lock handle code in fast_lock/fast_unlock > when UseOptoBiasInlining is true. > 2. Adjust biased_locking_enter’s actual parameters, swap disp_hdr and > box register. > 3. Fix typo in inflated monitor handling. > > Regards > Shi Hui

4 9

hg: aarch64-port/jdk8/hotspot: 8078521: AARCH64: Add AArch64 SA support
by aph＠redhat.com 27 Aug '15

27 Aug '15

Changeset: 1c4ef82d32d1 Author: aph Date: 2015-08-20 09:10 +0000 URL: http://hg.openjdk.java.net/aarch64-port/jdk8/hotspot/rev/1c4ef82d32d1 8078521: AARCH64: Add AArch64 SA support Summary: Add AArch64 SA support ! agent/make/Makefile ! agent/src/os/linux/LinuxDebuggerLocal.c ! agent/src/os/linux/Makefile ! agent/src/share/classes/sun/jvm/hotspot/HSDB.java + agent/src/share/classes/sun/jvm/hotspot/debugger/MachineDescriptionAARCH64.java + agent/src/share/classes/sun/jvm/hotspot/debugger/aarch64/AARCH64ThreadContext.java ! agent/src/share/classes/sun/jvm/hotspot/debugger/linux/LinuxCDebugger.java + agent/src/share/classes/sun/jvm/hotspot/debugger/linux/aarch64/LinuxAARCH64CFrame.java + agent/src/share/classes/sun/jvm/hotspot/debugger/linux/aarch64/LinuxAARCH64ThreadContext.java ! agent/src/share/classes/sun/jvm/hotspot/debugger/proc/ProcDebuggerLocal.java + agent/src/share/classes/sun/jvm/hotspot/debugger/proc/aarch64/ProcAARCH64Thread.java + agent/src/share/classes/sun/jvm/hotspot/debugger/proc/aarch64/ProcAARCH64ThreadContext.java + agent/src/share/classes/sun/jvm/hotspot/debugger/proc/aarch64/ProcAARCH64ThreadFactory.java + agent/src/share/classes/sun/jvm/hotspot/debugger/remote/aarch64/RemoteAARCH64Thread.java + agent/src/share/classes/sun/jvm/hotspot/debugger/remote/aarch64/RemoteAARCH64ThreadContext.java + agent/src/share/classes/sun/jvm/hotspot/debugger/remote/aarch64/RemoteAARCH64ThreadFactory.java ! agent/src/share/classes/sun/jvm/hotspot/runtime/Threads.java + agent/src/share/classes/sun/jvm/hotspot/runtime/aarch64/AARCH64CurrentFrameGuess.java + agent/src/share/classes/sun/jvm/hotspot/runtime/aarch64/AARCH64Frame.java + agent/src/share/classes/sun/jvm/hotspot/runtime/aarch64/AARCH64JavaCallWrapper.java + agent/src/share/classes/sun/jvm/hotspot/runtime/aarch64/AARCH64RegisterMap.java + agent/src/share/classes/sun/jvm/hotspot/runtime/linux_aarch64/LinuxAARCH64JavaThreadPDAccess.java ! agent/src/share/classes/sun/jvm/hotspot/utilities/PlatformInfo.java ! make/linux/makefiles/defs.make ! make/linux/makefiles/sa.make ! make/linux/makefiles/saproc.make ! make/sa.files

1 0

HotSpot debugger for JDK8
by Andrew Haley 26 Aug '15

26 Aug '15

http://cr.openjdk.java.net/~aph/jdk8-hsdb/ This is a fairly straightforward backport from JDK9. Andrew.

1 0

An interesting bug
by Andrew Haley 24 Aug '15

24 Aug '15

This is JDK8 on AArch64. I have an interesting bug which causes a crash. Occasionally, but rarely, I get a crash when accessing an instance of ForkJoinTask. The instance is allocated in the old generation of the parallel scan GC. However, the "this" pointer of the ForkJoinTask points into the middle of another allocated object. I'm trying to figure out how this might happen. Perhaps the root scan of the thread running the ForkJoinTask did not happen, or for some reason the roots it found were not added to the root set. Or perhaps they were found, but were not rewritten in the thread. Has anyone seen anything like this before? Do you have any advice for me? Thanks, Andrew.

1 1

Patches to backport to jdk8
by Edward Nevill 24 Aug '15

24 Aug '15

Hi, Is it OK to backport the following patches from jdk9 to jdk8. All the best, Ed. --- CUT HERE --- changeset: 8690:e4304d76473f user: enevill date: Wed Jul 15 16:05:53 2015 +0000 files: src/cpu/aarch64/vm/aarch64.ad description: 8131358: aarch64: test compiler/loopopts/superword/ProdRed_Float.java fails when run with debug VM Summary: fix typo in match rule in vsub2f Reviewed-by: kvn, aph ---------------- changeset: 8693:aa7220a36fb0 user: enevill date: Thu Jul 16 14:16:44 2015 +0000 files: src/cpu/aarch64/vm/assembler_aarch64.cpp src/cpu/aarch64/vm/assembler_aarch64.hpp src/cpu/aarch64/vm/macroAssembler_aarch64.cpp description: 8131483: aarch64: illegal stlxr instructions Summary: Do not generate stlxX with Ws == Xn Reviewed-by: kvn, aph ---------------- changeset: 8721:89a220e70e99 user: enevill date: Fri Jul 17 07:50:36 2015 +0000 files: src/cpu/aarch64/vm/aarch64.ad src/cpu/aarch64/vm/macroAssembler_aarch64.cpp src/cpu/aarch64/vm/macroAssembler_aarch64.hpp description: 8131362: aarch64: C2 does not handle large stack offsets Summary: change spill code to allow large offsets Reviewed-by: kvn, aph ---------------- changeset: 8840:8783515c57ad user: enevill date: Tue Aug 18 12:40:22 2015 +0000 files: src/cpu/aarch64/vm/assembler_aarch64.cpp src/cpu/aarch64/vm/assembler_aarch64.hpp src/cpu/aarch64/vm/interp_masm_aarch64.cpp src/cpu/aarch64/vm/macroAssembler_aarch64.cpp src/cpu/aarch64/vm/macroAssembler_aarch64.hpp src/cpu/aarch64/vm/sharedRuntime_aarch64.cpp src/cpu/aarch64/vm/templateInterpreter_aarch64.cpp description: 8133352: aarch64: generates constrained unpredictable instructions Summary: Fix generation of unpredictable STXR Rs, Rt, [Rn] with Rs == Rt Reviewed-by: kvn, aph, adinn ---------------- changeset: 8842:a94519010b13 tag: tip user: enevill date: Thu Aug 20 09:40:08 2015 +0000 files: src/cpu/aarch64/vm/aarch64.ad src/cpu/aarch64/vm/aarch64_ad.m4 description: 8133842: aarch64: C2 generates illegal instructions with int shifts >=32 Summary: Fix logical operatations combined with shifts >= 32 Reviewed-by: duke --- CUT HERE ---

2 1

RFR: aarch64: 8133842: C2 generates illegal instructions with int shifts >=32
by Edward Nevill 20 Aug '15

20 Aug '15

Hi, The following webrev http://cr.openjdk.java.net/~enevill/8133842/webrev.01/ fixes a problem reported by one of our partners whereby C2 can generate illegal instructions on certain partners HW. JIRA issue here https://bugs.openjdk.java.net/browse/JDK-8133842 The problem occurs when you have a logical or arithmetic instruction with a RHS which is shifted by a constant where (const & 32) != 0, ie the constant is 32..63 or 96..127 etc. For example the following res = i | (j >> 53) generates the instruction orrw Rd, Rn, Rm, ASR #53 This instruction has a 6 bit field for the shift so this would appear to be a legal encoding. However certain partner HW treats this as an undefined instruction generating a SIGILL. The problem was that the rules in aarch64.ad were always anding the constant with 0x3f for both ints and longs. The above webrev fixes this to mask with 0x1f for ints and 0x3f for longs. Tested with hotspot and langtools. Results the same in both cases. Hotspot: Test results: passed: 863; failed: 2; error: 10 Langtools: Test results: passed: 3,263 Thanks for your help with this review, Ed.

4 7

Re: [aarch64-port-dev ] RFR: 8078743: AARCH64: Extend use of stlr to cater for volatile object stores
by Edward Nevill 19 Aug '15

19 Aug '15

Hi Andrew, I have tested this on two different partner platforms with G1GC, CMS and Parallel GC with and without UseCondCardMark. I have also reviewed the code and and happy with the code and comments. Vladimir, if you are still happy with this may I go ahead and push this on behalf of Andrew Dinn. The changes only affect aarch64.ad. Many thanks, Ed. On Wed, 2015-08-12 at 13:45 +0100, Andrew Dinn wrote: > Hi Vladimir, > > Apologies for the delay in responding to your feedback -- I was > traveling for a team meeting all of last week. > > Here is a revised webrev which includes all the code changes you suggested > > http://cr.openjdk.java.net/~adinn/8078743/webrev.04 >

2 1