February 2016 - aarch64-port-dev

RFR: 8149733: AArch64: refactor char_array_equals/byte_array_equals/string_equals
by Hui Shi 23 Feb '16

23 Feb '16

Hi, Could some one help review this patch? This patch mainly aims to refactoring similar code on AArch64 for string equals/ char array equals and byte array equals. JIRA: https://bugs.openjdk.java.net/browse/JDK-8149733 webrev: http://cr.openjdk.java.net/~hshi/8149733/webrev/ Patch includes: 1. Add new method MacroAssembler::generic_arrays_equals method, its implementation combines string_equals and char/byte_array_equals. For array length >= 8 bytes, compare main body and tail bytes in 8 bytes wide. Same with current string equals' implementation. This eliminates tail branches and loads and improve performance on short length compare. For array length < 8 bytes, compare in test-ld-cmp sequence. It out performs loop copy in string_equals. 2. Remove unnecessary lea address computation (mov array pointer to last word) in string_equals. 3. Remove unnecessary tmp register for string_equals. JTreg doesn’t show regression and performance also doesn't degradate with different length combination. Small char/byte equals improves in most tests. There is one slow run with new implementation, because last several chars are different in test case. Original char array equals can find the difference with first test-ld-cmp check, test-ld-cmp sequence might be faster than entire unaligned 8 byte compare in some corner cases. Test different chars in middle of string, performance is close for both implementation. Test case: http://cr.openjdk.java.net/~hshi/8149733/TestArrayEqual.java Test result: http://cr.openjdk.java.net/~hshi/8149733/ArrayEqual.pdf Regards Hui

3 4

Re: [aarch64-port-dev ] RFR(S): 8087341: C2 doesn't optimize redundant memory operations with G1
by Andrew Dinn 19 Feb '16

19 Feb '16

Hi Roland, A patch for the AArch64 C2 volatile/CAS generation code which deals with the effects of your proposed C2 patch is available as a webrev http://cr.openjdk.java.net/~adinn/8087341-aarch64/webrev.00/ The webrev includes your patch and mine and is based on the latest hs-comp. n.b. I have /not/ created a separate issue for the AArch64 part of this fix. I am not sure whether you want to combine it with your patch or push it as a separate stage. n.b. your patch allowed the AArch64 C2 code to be significantly simplified. That's because it ensures that the Raw memory flows associated with the GC card marks no longer intermingle with the AliasIdxBot and oop flows associated with the volatile store/CAS. This means the job of recognising the signature memory configuration between leading and trailing memory barriers is much easier. Testing: I have verified that this generates correct code for volatile put and CAS on AArch64 in all 5 relevant GC configurations: +UseG1GC +UseConcMarkSweepGC +CondCardMark +UseConcMarkSweepGC -CondCardMark +UseParallelGC +CondCardMark +UseParallelGC -CondCardMark A review from an AArch64 reviewer would be welcome. regards, Andrew Dinn ----------- Senior Principal Software Engineer Red Hat UK Ltd Registered in UK and Wales under Company Registration No. 3798903 Directors: Michael Cunningham (US), Michael O'Neill (Ireland), Paul Argiry (US)

4 13

RFR: 8149907: aarch64: use load/store pair instructions in call_stub
by Felix Yang 18 Feb '16

18 Feb '16

Hi, Please review the following webrev: http://cr.openjdk.java.net/~fyang/8149907/webrev.00/ Jira issue: https://bugs.openjdk.java.net/browse/JDK-8149907 This patch make use of load/store pair instructions in call_stub saving 24 load/store instructions. Tested with jtreg hotspot & langtools. Is it OK? Thanks, Felix.

2 4

RFR: 8150038: aarch64: make use of CBZ and CBNZ when comparing narrow pointer with zero
by Felix Yang 17 Feb '16

17 Feb '16

Hi, Please review the following webrev: *http://cr.openjdk.java.net/~fyang/8150038/webrev.00/ <http://cr.openjdk.java.net/~fyang/8150038/webrev.00/>* Jira issue: *https://bugs.openjdk.java.net/browse/JDK-8150038 <https://bugs.openjdk.java.net/browse/JDK-8150038>* For several times I noticed the following pattern in C2 JIT code (the java heap size is set to 200MB): 2042 0x0000007f6c9419c4: ldr w14, [x11,#32] ;*getfield buffer 2048 0x0000007f6c9419c8: cmp w14, wzr 2049 0x0000007f6c9419cc: b.eq 0x0000007f6c9425e4 ;*invokevirtual reset The two cmp and b.eq instructions can be combined into one "cbz" instruction. Currently, the aarch64 port only makes use of CBZ and CBNZ when comparing operands with Integer/Long/Pointer type with zero. Patch fixes the issue by adding one similar combine pattern in the AD file for Narrow pointer types(just like the sparc port does). Tested with jtreg hotspot & langtools. Is it OK? Thanks, Felix.

2 1

AArch64: follow up array copy investigation on misaligned peeling
by Hui Shi 17 Feb '16

17 Feb '16

Hi Andrew and all, Follow up with early discussion about forward and backward array copy performance, current finding is 1. Optimizing misaligned load/store in backward array copy doesn't help on array copy performance, I suggest leave it unchanged now. 2. There is some chances to optimizing array copy peeling/tailing with combined 8 byte load/store. But might introduce extra stubs and complicate code. Would you please help comment? Firstly, remove unaligned reference by reorder copy orders from small to large (copy 1 byte first, 8 byte at last) when peeling. However it is even a little bit slow compared with original implementation. Test case is http://people.linaro.org/~hui.shi/arraycopy/TestPeelAlign.java Performance result in http://people.linaro.org/~hui.shi/arraycopy/arraycopy_align_and_combine_Tes… Patch is http://people.linaro.org/~hui.shi/arraycopy/peelingFromSmall.patch Test case is typical backward array copy scenario (insert some element in array and move tail array backward). From profiling, UNALIGNED_LDST_SPEC event drops a lot with patch. In my understanding, load address cross cache line boundary might trigger hardware prefetcher earlier than aligned access. So fixing unaligned access seems not helpful in array copy peeling. Secondly, as unaligned access doesn't show degradation in this case, further experiment is folding consecutive branches/load/stores into one 8 byte unaligned load/store. Following is updated stub code for byte array copy. This is legal when src and dst distance is bigger than 8 bytes. This is safe in cases like String.getChars String.getBytes. Perform different combination tests, it works best for byte array copy and still helpful for short array copy. Check result in pdf "opt" column is for this optimization. For StringConcat test ( http://people.linaro.org/~hui.shi/arraycopy/StringConcatTest.java) though array copy only takes 25% cycles in this test, entire test can still see 3.5% improvement with this combine load/store optimization. However I wondering if this is the proper way to improve these test-bit-load-store code sequence. This will requires extra really “disjoint” array copy stub code, current disjoint array copy only means it can safely perform forward array copy. Or introduce no "overlap" test at runtime. My personal tradeoff is leaving array copy code unchanged and keep it simply and consistent now. Before patch StubRoutines::jbyte_disjoint_arraycopy [0x0000ffff7897f7c0, 0x0000ffff7897f860[ (160 bytes) 0x0000ffff7897f7e0: tbz w9, #3, Stub::jbyte_disjoint_arraycopy+44 0x0000ffff7897f7ec 0x0000ffff7897f7e4: ldr x8, [x0],#8 0x0000ffff7897f7e8: str x8, [x1],#8 0x0000ffff7897f7ec: tbz w9, #2, Stub::jbyte_disjoint_arraycopy+56 0x0000ffff7897f7f8 0x0000ffff7897f7f0: ldr w8, [x0],#4 0x0000ffff7897f7f4: str w8, [x1],#4 0x0000ffff7897f7f8: tbz w9, #1, Stub::jbyte_disjoint_arraycopy+68 0x0000ffff7897f804 0x0000ffff7897f7fc: ldrh w8, [x0],#2 0x0000ffff7897f800: strh w8, [x1],#2 0x0000ffff7897f804: tbz w9, #0, Stub::jbyte_disjoint_arraycopy+80 0x0000ffff7897f810 0x0000ffff7897f808: ldrb w8, [x0],#1 0x0000ffff7897f80c: strb w8, [x1],#1 0x0000ffff7897f810: cmp x2, #0x10 0x0000ffff7897f814: b.lt Stub::jbyte_disjoint_arraycopy+96 0x0000ffff7897f820 0x0000ffff7897f818: lsr x9, x2, #3 0x0000ffff7897f81c: bl Stub::foward_copy_longs+28 0x0000ffff7897f5c0 Code after patch StubRoutines::jbyte_disjoint_arraycopy [0x0000ffff6c97f7c0, 0x0000ffff6c97f87c[ (188 bytes) // peeling for alignment 0x0000ffff6c97f7e0: tbz w9, #3, Stub::jbyte_disjoint_arraycopy+48 0x0000ffff6c97f7f0 0x0000ffff6c97f7e4: sub x9, x9, #0x8 0x0000ffff6c97f7e8: ldr x8, [x0],#8 0x0000ffff6c97f7ec: str x8, [x1],#8 0x0000ffff6c97f7f0: ldr x8, [x0] 0x0000ffff6c97f7f4: str x8, [x1] 0x0000ffff6c97f7f8: add x0, x0, x9 0x0000ffff6c97f7fc: add x1, x1, x9 0x0000ffff6c97f800: cmp x2, #0x10 0x0000ffff6c97f804: b.lt Stub::jbyte_disjoint_arraycopy+124 0x0000ffff6c97f83c 0x0000ffff6c97f808: lsr x9, x2, #3 0x0000ffff6c97f80c: bl Stub::foward_copy_longs+28 0x0000ffff6c97f5c0 Regards Hui

2 1

Sync AArch64 8u JDK Repository with upstream 8u72
by Andrew Hughes 12 Feb '16

12 Feb '16

I did a comparison of the AArch64 jdk8u repository [0] with the upstream jdk8u72-b15 tag and found a couple of differences that could be resolved. 1. The change "8131105: Header Template for nroff man pages *.1 files contains errors" seems to have been reverted. Re-applying this fixes the issue. 2. Two solutions for a libpng on ARM issue [1] seem to have been applied. Now that the upstream 8078245 version is present, we can revert the change to the libpng sources, keeping them pristine and making it easier to apply future upstream updates to them. Webrev: http://cr.openjdk.java.net/~andrew/aarch64-8/sync/jdk.webrev.01/webrev/ Ok to push? [0] http://hg.openjdk.java.net/aarch64-port/jdk8u/jdk/ [1] https://bugs.openjdk.java.net/browse/JDK-8078245 Thanks, -- Andrew :) Senior Free Java Software Engineer Red Hat, Inc. (http://www.redhat.com) PGP Key: ed25519/35964222 (hkp://keys.gnupg.net) Fingerprint = 5132 579D D154 0ED2 3E04 C5A0 CFDA 0F9B 3596 4222

2 2

hg: aarch64-port/jdk8u/jdk: 2 new changesets
by gnu.andrew＠redhat.com 12 Feb '16

12 Feb '16

Changeset: c57b985d9249 Author: mfang Date: 2015-07-15 12:12 -0700 URL: http://hg.openjdk.java.net/aarch64-port/jdk8u/jdk/rev/c57b985d9249 8131105: Header Template for nroff man pages *.1 files contains errors Reviewed-by: katleman ! src/bsd/doc/man/appletviewer.1 ! src/bsd/doc/man/extcheck.1 ! src/bsd/doc/man/idlj.1 ! src/bsd/doc/man/jar.1 ! src/bsd/doc/man/jarsigner.1 ! src/bsd/doc/man/java.1 ! src/bsd/doc/man/javac.1 ! src/bsd/doc/man/javadoc.1 ! src/bsd/doc/man/javah.1 ! src/bsd/doc/man/javap.1 ! src/bsd/doc/man/jcmd.1 ! src/bsd/doc/man/jconsole.1 ! src/bsd/doc/man/jdb.1 ! src/bsd/doc/man/jdeps.1 ! src/bsd/doc/man/jhat.1 ! src/bsd/doc/man/jinfo.1 ! src/bsd/doc/man/jjs.1 ! src/bsd/doc/man/jmap.1 ! src/bsd/doc/man/jps.1 ! src/bsd/doc/man/jrunscript.1 ! src/bsd/doc/man/jsadebugd.1 ! src/bsd/doc/man/jstack.1 ! src/bsd/doc/man/jstat.1 ! src/bsd/doc/man/jstatd.1 ! src/bsd/doc/man/keytool.1 ! src/bsd/doc/man/native2ascii.1 ! src/bsd/doc/man/orbd.1 ! src/bsd/doc/man/pack200.1 ! src/bsd/doc/man/policytool.1 ! src/bsd/doc/man/rmic.1 ! src/bsd/doc/man/rmid.1 ! src/bsd/doc/man/rmiregistry.1 ! src/bsd/doc/man/schemagen.1 ! src/bsd/doc/man/serialver.1 ! src/bsd/doc/man/servertool.1 ! src/bsd/doc/man/tnameserv.1 ! src/bsd/doc/man/unpack200.1 ! src/bsd/doc/man/wsgen.1 ! src/bsd/doc/man/wsimport.1 ! src/bsd/doc/man/xjc.1 ! src/linux/doc/man/appletviewer.1 ! src/linux/doc/man/extcheck.1 ! src/linux/doc/man/idlj.1 ! src/linux/doc/man/ja/appletviewer.1 ! src/linux/doc/man/ja/extcheck.1 ! src/linux/doc/man/ja/idlj.1 ! src/linux/doc/man/ja/jar.1 ! src/linux/doc/man/ja/jarsigner.1 ! src/linux/doc/man/ja/java.1 ! src/linux/doc/man/ja/javac.1 ! src/linux/doc/man/ja/javadoc.1 ! src/linux/doc/man/ja/javah.1 ! src/linux/doc/man/ja/javap.1 ! src/linux/doc/man/ja/javaws.1 ! src/linux/doc/man/ja/jcmd.1 ! src/linux/doc/man/ja/jconsole.1 ! src/linux/doc/man/ja/jdb.1 ! src/linux/doc/man/ja/jdeps.1 ! src/linux/doc/man/ja/jhat.1 ! src/linux/doc/man/ja/jinfo.1 ! src/linux/doc/man/ja/jjs.1 ! src/linux/doc/man/ja/jmap.1 ! src/linux/doc/man/ja/jps.1 ! src/linux/doc/man/ja/jrunscript.1 ! src/linux/doc/man/ja/jsadebugd.1 ! src/linux/doc/man/ja/jstack.1 ! src/linux/doc/man/ja/jstat.1 ! src/linux/doc/man/ja/jstatd.1 ! src/linux/doc/man/ja/jvisualvm.1 ! src/linux/doc/man/ja/keytool.1 ! src/linux/doc/man/ja/native2ascii.1 ! src/linux/doc/man/ja/orbd.1 ! src/linux/doc/man/ja/pack200.1 ! src/linux/doc/man/ja/policytool.1 ! src/linux/doc/man/ja/rmic.1 ! src/linux/doc/man/ja/rmid.1 ! src/linux/doc/man/ja/rmiregistry.1 ! src/linux/doc/man/ja/schemagen.1 ! src/linux/doc/man/ja/serialver.1 ! src/linux/doc/man/ja/servertool.1 ! src/linux/doc/man/ja/tnameserv.1 ! src/linux/doc/man/ja/unpack200.1 ! src/linux/doc/man/ja/wsgen.1 ! src/linux/doc/man/ja/wsimport.1 ! src/linux/doc/man/ja/xjc.1 ! src/linux/doc/man/jar.1 ! src/linux/doc/man/jarsigner.1 ! src/linux/doc/man/java.1 ! src/linux/doc/man/javac.1 ! src/linux/doc/man/javadoc.1 ! src/linux/doc/man/javah.1 ! src/linux/doc/man/javap.1 ! src/linux/doc/man/jcmd.1 ! src/linux/doc/man/jconsole.1 ! src/linux/doc/man/jdb.1 ! src/linux/doc/man/jdeps.1 ! src/linux/doc/man/jhat.1 ! src/linux/doc/man/jinfo.1 ! src/linux/doc/man/jjs.1 ! src/linux/doc/man/jmap.1 ! src/linux/doc/man/jps.1 ! src/linux/doc/man/jrunscript.1 ! src/linux/doc/man/jsadebugd.1 ! src/linux/doc/man/jstack.1 ! src/linux/doc/man/jstat.1 ! src/linux/doc/man/jstatd.1 ! src/linux/doc/man/keytool.1 ! src/linux/doc/man/native2ascii.1 ! src/linux/doc/man/orbd.1 ! src/linux/doc/man/pack200.1 ! src/linux/doc/man/policytool.1 ! src/linux/doc/man/rmic.1 ! src/linux/doc/man/rmid.1 ! src/linux/doc/man/rmiregistry.1 ! src/linux/doc/man/schemagen.1 ! src/linux/doc/man/serialver.1 ! src/linux/doc/man/servertool.1 ! src/linux/doc/man/tnameserv.1 ! src/linux/doc/man/unpack200.1 ! src/linux/doc/man/wsgen.1 ! src/linux/doc/man/wsimport.1 ! src/linux/doc/man/xjc.1 ! src/solaris/doc/sun/man/man1/appletviewer.1 ! src/solaris/doc/sun/man/man1/extcheck.1 ! src/solaris/doc/sun/man/man1/idlj.1 ! src/solaris/doc/sun/man/man1/ja/appletviewer.1 ! src/solaris/doc/sun/man/man1/ja/extcheck.1 ! src/solaris/doc/sun/man/man1/ja/idlj.1 ! src/solaris/doc/sun/man/man1/ja/jar.1 ! src/solaris/doc/sun/man/man1/ja/jarsigner.1 ! src/solaris/doc/sun/man/man1/ja/java.1 ! src/solaris/doc/sun/man/man1/ja/javac.1 ! src/solaris/doc/sun/man/man1/ja/javadoc.1 ! src/solaris/doc/sun/man/man1/ja/javah.1 ! src/solaris/doc/sun/man/man1/ja/javap.1 ! src/solaris/doc/sun/man/man1/ja/jcmd.1 ! src/solaris/doc/sun/man/man1/ja/jconsole.1 ! src/solaris/doc/sun/man/man1/ja/jdb.1 ! src/solaris/doc/sun/man/man1/ja/jdeps.1 ! src/solaris/doc/sun/man/man1/ja/jhat.1 ! src/solaris/doc/sun/man/man1/ja/jinfo.1 ! src/solaris/doc/sun/man/man1/ja/jjs.1 ! src/solaris/doc/sun/man/man1/ja/jmap.1 ! src/solaris/doc/sun/man/man1/ja/jps.1 ! src/solaris/doc/sun/man/man1/ja/jrunscript.1 ! src/solaris/doc/sun/man/man1/ja/jsadebugd.1 ! src/solaris/doc/sun/man/man1/ja/jstack.1 ! src/solaris/doc/sun/man/man1/ja/jstat.1 ! src/solaris/doc/sun/man/man1/ja/jstatd.1 ! src/solaris/doc/sun/man/man1/ja/jvisualvm.1 ! src/solaris/doc/sun/man/man1/ja/keytool.1 ! src/solaris/doc/sun/man/man1/ja/native2ascii.1 ! src/solaris/doc/sun/man/man1/ja/orbd.1 ! src/solaris/doc/sun/man/man1/ja/pack200.1 ! src/solaris/doc/sun/man/man1/ja/policytool.1 ! src/solaris/doc/sun/man/man1/ja/rmic.1 ! src/solaris/doc/sun/man/man1/ja/rmid.1 ! src/solaris/doc/sun/man/man1/ja/rmiregistry.1 ! src/solaris/doc/sun/man/man1/ja/schemagen.1 ! src/solaris/doc/sun/man/man1/ja/serialver.1 ! src/solaris/doc/sun/man/man1/ja/servertool.1 ! src/solaris/doc/sun/man/man1/ja/tnameserv.1 ! src/solaris/doc/sun/man/man1/ja/unpack200.1 ! src/solaris/doc/sun/man/man1/ja/wsgen.1 ! src/solaris/doc/sun/man/man1/ja/wsimport.1 ! src/solaris/doc/sun/man/man1/ja/xjc.1 ! src/solaris/doc/sun/man/man1/jar.1 ! src/solaris/doc/sun/man/man1/jarsigner.1 ! src/solaris/doc/sun/man/man1/java.1 ! src/solaris/doc/sun/man/man1/javac.1 ! src/solaris/doc/sun/man/man1/javadoc.1 ! src/solaris/doc/sun/man/man1/javah.1 ! src/solaris/doc/sun/man/man1/javap.1 ! src/solaris/doc/sun/man/man1/jcmd.1 ! src/solaris/doc/sun/man/man1/jconsole.1 ! src/solaris/doc/sun/man/man1/jdb.1 ! src/solaris/doc/sun/man/man1/jdeps.1 ! src/solaris/doc/sun/man/man1/jhat.1 ! src/solaris/doc/sun/man/man1/jinfo.1 ! src/solaris/doc/sun/man/man1/jjs.1 ! src/solaris/doc/sun/man/man1/jmap.1 ! src/solaris/doc/sun/man/man1/jps.1 ! src/solaris/doc/sun/man/man1/jrunscript.1 ! src/solaris/doc/sun/man/man1/jsadebugd.1 ! src/solaris/doc/sun/man/man1/jstack.1 ! src/solaris/doc/sun/man/man1/jstat.1 ! src/solaris/doc/sun/man/man1/jstatd.1 ! src/solaris/doc/sun/man/man1/keytool.1 ! src/solaris/doc/sun/man/man1/native2ascii.1 ! src/solaris/doc/sun/man/man1/orbd.1 ! src/solaris/doc/sun/man/man1/pack200.1 ! src/solaris/doc/sun/man/man1/policytool.1 ! src/solaris/doc/sun/man/man1/rmic.1 ! src/solaris/doc/sun/man/man1/rmid.1 ! src/solaris/doc/sun/man/man1/rmiregistry.1 ! src/solaris/doc/sun/man/man1/schemagen.1 ! src/solaris/doc/sun/man/man1/serialver.1 ! src/solaris/doc/sun/man/man1/servertool.1 ! src/solaris/doc/sun/man/man1/tnameserv.1 ! src/solaris/doc/sun/man/man1/unpack200.1 ! src/solaris/doc/sun/man/man1/wsgen.1 ! src/solaris/doc/sun/man/man1/wsimport.1 ! src/solaris/doc/sun/man/man1/xjc.1 Changeset: f9d3631fbc8f Author: andrew Date: 2016-02-08 14:55 +0000 URL: http://hg.openjdk.java.net/aarch64-port/jdk8u/jdk/rev/f9d3631fbc8f Revert changes to libpng source code now 8078245 is in place. ! src/share/native/sun/awt/libpng/pngpriv.h

1 0

RFR(s): AAch64: Adding byte array equal support
by Hui Shi 12 Feb '16

12 Feb '16

Hi All, Would someone help review this patch for adding byte array equal support on aarch64? bug: https://bugs.openjdk.java.net/browse/JDK-8149100 webrev: http://cr.openjdk.java.net/~hshi/8149100/webrev/ For http://cr.openjdk.java.net/~hshi/8149100/testcase/ArrayEqual.java, debug build run will failed with “bad AD file” assertion on aarch64. # To suppress the following error report, specify this argument # after -XX: or in .hotspotrc: SuppressErrorAt=/matcher.cpp:1605 # # A fatal error has been detected by the Java Runtime Environment: # # Internal Error (/home/shihui/jdk9-hs-comp/hotspot/src/share/vm/opto/matcher.cpp:1605), pid=8501, tid=8746 # assert(false) failed: bad AD file # Debugg shows AryEqNode’s enconding is StrIntrinsicNode::LL, which is not supported on aarch64 now. 1605 assert( false, "bad AD file" ); (gdb) p ((AryEqNode*)n)->encoding() $1 = StrIntrinsicNode::LL (gdb) Fix is adding support for StrIntrinsicNode::LL encoding array equal operation, as Latin String compare might become important in JDK9 with new String. 1. Adding MacroAssembler::byte_arrays_equals to support byte array equals check. 2. Add new array_equalsB rule when AryEq enconding is StrIntrinsicNode::LL. http://cr.openjdk.java.net/~hshi/8149100/testcase/byte_array_equals.asm shows newly generated assembly. Relase build will invoke Array.equals method before this patch, with this patch, significant improvment on ArrayEqual case. time -p openjdk-9-internal.base/bin/java ArrayEqual real 54.98 user 55.13 time -p openjdk-9-internal.byteEquals/bin/java ArrayEqual real 28.59 user 28.62 sys 0.14 Following code sequence can be replaced with tbz (when tst has constant exactly two’s n times value), these code sequence exist in other places(MacroAssembler::char_arrays_equals, interpreter, etc). I would like clean all together in another separate changeset. tst(cnt1, 0b10); br(EQ, TAIL01); Regards Hui

2 6

RFR(s): AArch64: 8149080: Recoginize disjoint array copy in stub code
by Hui Shi 10 Feb '16

10 Feb '16

Hi, Would some one help review this changeset? This improves performance for codes like string builder and concat on aarch64. Bug: https://bugs.openjdk.java.net/browse/JDK-8149080 webrev: http://cr.openjdk.java.net/~hshi/8149080/webrev/ Arraycopy without overlapping is faster than overlapped copy. If overlap information is unknown at JIT time, stub code will check if arraycopy src and dest array overlap at runtime, if not overlap, stub will perform faster none-overlap array copy. In current aarch64 implementation, stub code checks only if dest below src, this doesn’t cover cases dest above src but still not overlap case (as X86 did). Fixing is checking both conditions, if (dest-src) is above/equal (copy size), it's not overlap and stub code can jump to none overlapping copy. Another modification is adding StubCodeMark for backward/forward copy longs on aarch64, so code in these sections can get profiled with correct stub name. Regards Hui

3 14

RFR: 8149365: memory copy does not prefetch on backwards copy
by Edward Nevill 08 Feb '16

08 Feb '16

Hi, The following webrev http://cr.openjdk.java.net/~enevill/8149365/webrev.0/ adds support for prefetch on backwards copies (previously prefetch was only done on forwards copies). It also fixes a 'feature' where the command line option -XX:PrefetchCopyIntervalInBytes=N is ignored and the value 256 always used instead. I have benchmarked it using the following test progam http://cr.openjdk.java.net/~enevill/8149365/ArrayCopyTest.java Which allows you to test memory copies of different sizes from a start size to an end size in step units. The test does both backwards and forwards copies. Usage: java ArrayCopyTest <iters> <start> <end> <step> I have generated the results obtained before and after the above patch on 4 different partners HW (A,B,C,D) and a summary of the results is available at http://people.linaro.org/~edward.nevill/prefetch/prefetch.pdf For partner A I tested 3 ranges 0-64 bytes in units of 1 0-512 bytes in units of 8 0-4096 bytes in units of 64 The latter 2 clearly show the benefit of prefetching on backwards copies. For partners B, C & D, I only tested 0-4096 bytes in units of 64. I also tested B, C & D with -XX:PrefetchCopyIntervalInBytes=0. On these 3 partners disabling prefetch seemed to have no effect indicating that either prefetch is not implemented, or it implements automatic hardware prefetch. A summary of the results is that it improves performance significantly on partner A and has no effect on partners B,C & D. OK to push? Ed.

2 1