June 2016 - aarch64-port-dev

RFR: 8159052: aarch64: optimise unaligned copies in pd_disjoint_words and pd_conjoint_words
by Edward Nevill 18 Jul '16

18 Jul '16

Hi, Please review the following webrev http://cr.openjdk.java.net/~enevill/8159052/webrev JIRA Issue: https://bugs.openjdk.java.net/browse/JDK-8159052 Some partners HW has large unaligned access penalties. This webrev optimises unaligned copies in pd_disjoint_words and pd_conjoint_words. There is no performance degradation on other partners HW. The following JMH test was used to benchmark performance. http://cr.openjdk.java.net/~enevill/8159052/JMHSample_97_GCStress.java The following graphs show the performance of the above test on two partners HW, partner A which has a penalty for unaligned accesses and partner B which does not. The test was repeated for three different garbage collectors, G1GC, ParallelGC and CMS. The units are time, so lower is better. http://cr.openjdk.java.net/~enevill/8159052/gcstress_res.pdf I understand that this cannot be pushed to jdk 9 at the moment because jdk 9 is FC, however I would like to push this to the aarch64 port jdk8u repo so it has a save home to be migrated to jdk 9/jdk 9u/jdk 10 in the future. OK to push to jdk8u? Ed.

3 2

aarch64: Fix a bug in TestOptionsWithRanges of hotspot
by Yang Zhang 08 Jul '16

08 Jul '16

Hi Could someone please help to review and process attached patch for fixing an issue about BlockZeroingLowLimit in hotspot openjdk9 aarch64? This issue is exposed by a test failure in hotspot jtreg openjdk9 for aarch64 runtime/CommandLine/OptionsValidation/TestOptionsWithRanges.java It is caused by improper range of BlockZeroingLowLimit. The issue can be reproduced by command as follows: $ java -server -XX:+UseG1GC -XX:BlockZeroingLowLimit=2147483647 The attached patch can fix this issue and the jtreg test failure above (and no new failure found). Regards Yang

3 9

RFR: 8157708: aarch64: StrIndexOfChar intrinsic is not implemented
by Edward Nevill 06 Jul '16

06 Jul '16

Hi, Please review the following webrev http://cr.openjdk.java.net/~enevill/8157708/webrev This implements the StrIndexOfChar on aarch64. This webrev has been contributed by ningsheng.jian(a)linaro.org Tested with fastdebug jtreg hotspot and langtools. Note: That this changeset needs to be applied after the changeset to implement StrIndexOf otherwise there will be "bad AD" errors in the jtreg test run, but this is due to missing StrIndexOf implementations. All the best, Ed.

3 5

Re: [aarch64-port-dev ] RFR: 8156943: aarch64: string compare does not support CompactStrings
by Edward Nevill 05 Jul '16

05 Jul '16

On Fri, 2016-05-20 at 17:00 +0100, Andrew Haley wrote: > On 05/20/2016 04:56 PM, Edward Nevill wrote: > > fcmpd(vtmpZ, 0.0) generates EQ iff the lower 64 bits of vtmpZ are 0 > > otherwise NE. > > > > If it is the case that fcmpd generates EQ for some bit pattern other than > > all 64 bits 0 then indeed it is broken. > > There are two zeroes, +0 and -0. > > Andrew. The following webrev fixes this by instead moving the simd registers to general registers. http://cr.openjdk.java.net/~enevill/8156943/webrev.02/ The different cases are handled as follows LL: 8 chars are loaded to each of 2 general regs UU: 4 chars are loaded to each of 2 general regs LU/UL: 4 U chars loaded to 1 general regs, 4 L chars loaded to a simd reg, zip1 used to convert L to U and then moved to a general reg. Tested fastdebug jtreg hotspot and langtools, All the best, Ed.

3 10

Fireside chat
by Stuart Monteith 30 Jun '16

30 Jun '16

Hello, It has been a fortnight since the last chat, let's have another one today. The time is 15:00 UTC, 16:00 BST and the details are as follow: https://bluejeans.com/791239268 This is an open conference call where anyone who is involved in or interested in the aarch64 port of OpenJDK can join in to voice their suggestions, ask questions, air their grievances or just tell us how well we are doing. If you have not used BlueJeans before please try the above link in advance as it needs to do some downloads first time it starts. Alternatively you may dial in using one of the following numbers http://bluejeans.com/numbers and enter the Meeting ID: 791239268 Please do not use any of the 'freefone' numbers, because although they may be free for you they cost us $$$$. Regards, Stuart

1 0

Re: [aarch64-port-dev ] [9] RFR (S): 8159431: C1 arraycopy intrinsic type checks missing
by Vladimir Kozlov 28 Jun '16

28 Jun '16

Looks good. But you need to fix ot for aarch64 and ppc64 too. Please, ask SAP and RH for help with code and testing change if needed. Thanks, Vladimir On 6/27/16 11:20 AM, Zoltán Majó wrote: > Hi Vladimir, > > > thank you for the feedback! > > On 06/25/2016 12:56 AM, Vladimir Kozlov wrote: >> Zoltan, check that klass is not j.l.Object is not enough. >> See next code in stub generators how to check for arrays (similar code >> exists on all platforms): >> >> http://hg.openjdk.java.net/jdk9/hs-comp/hotspot/file/ff0c5aa32086/src/cpu/x… >> > > right, thank you for catching that! > > Here is the updated webrev: > http://cr.openjdk.java.net/~zmajo/8159431/webrev.01/ > > Testing: JPRT (testset hotspot). > > Thank you! > > Best regards, > > > Zoltan > >> >> Thanks, >> Vladimir >> >> On 6/24/16 9:05 AM, Zoltán Majó wrote: >>> Hi, >>> >>> >>> please review the patch for 8159431. >>> >>> https://bugs.openjdk.java.net/browse/JDK-8159431 >>> >>> Problem: The C1 intrinsic for >>> java.lang.System.arraycopy(Object src, int srcPos, Object dest, int >>> destPos, int length) >>> >>> does not verify that 'src' or 'dest' is a "proper" array. As a >>> result, the intrinsic reads the non-existing 'length' field from >>> java.lang.Object (i.e., the intrinsic reads past the end of the >>> java.lang.Object instance), which is incorrect. >>> >>> Also, the intrinsic only checks if 'src' is a subclass of 'dest' >>> before writing into 'dest' without checking the special case >>> 'dest'==java.lang.Object. That can result in data being written to a >>> random heap location instead of the required ArrayStoreException >>> being thrown. >>> >>> Solution: Check the type of 'src' and 'dest' at runtime if the >>> compiler was not able to prove at compile-time that 'src' and 'dest' >>> are "proper" arrays. >>> >>> Webrev: >>> http://cr.openjdk.java.net/~zmajo/8159431/webrev.00/ >>> >>> Testing: JPRT (testset hotspot). >>> >>> I'll do an RBT run once the code is close to its final shape. >>> >>> The problem was originally reported by Xiang Yuan from Linaro. Once >>> the code is reviewed, I plan to push the patch with Xiang and myself >>> as contributors. >>> >>> The open arm port and ppc are also likely to be affected. I'll file >>> bugs for those architectures and notify persons working on the >>> appropriate ports. >>> >>> Thank you! >>> >>> Best regards, >>> >>> >>> Zoltan >>> >

2 1

hg: aarch64-port/jdk8u/hotspot: 8159063: aarch64: optimise unaligned array copy long
by edward.nevill＠gmail.com 27 Jun '16

27 Jun '16

Changeset: 7badc785fb87 Author: enevill Date: 2016-06-24 10:35 +0000 URL: http://hg.openjdk.java.net/aarch64-port/jdk8u/hotspot/rev/7badc785fb87 8159063: aarch64: optimise unaligned array copy long Reviewed-by: aph Contributed-by: edward.nevill(a)gmail.com, adinn(a)redhat.com ! src/cpu/aarch64/vm/globals_aarch64.hpp ! src/cpu/aarch64/vm/stubGenerator_aarch64.cpp ! src/cpu/aarch64/vm/vm_version_aarch64.cpp

2 1

RFR: 8159063: aarch64: optimise unaligned array copy long
by Edward Nevill 24 Jun '16

24 Jun '16

Hi, Please review the following webrev http://cr.openjdk.java.net/~enevill/8159063/webrev JIRA Issue: https://bugs.openjdk.java.net/browse/JDK-8159063 This webrev optimises the code generate for copy array long to ensure that loads/stores are always done on 128 bit boundaries. This can be switched on/off with -XX:+/-AvoidUnalignedAccesses which is set by default for those partners where there is a benefit. The following is my test case. http://cr.openjdk.java.net/~enevill/8159063/ArrayCopyAligned.java To run do java ArrayCopyAligned <iters> <start> <end> <step> This shows the results for partners A and B with the parameters 10 0 1024 32. http://cr.openjdk.java.net/~enevill/8159063/arraycopy.pdf OK to push to jdk8u now (and later to jdk9)? Thanks, Ed.

4 10

RFR(S): 8158260: PPC64: unaligned Unsafe.getInt can lead to the generation of illegal instructions
by Volker Simonis 23 Jun '16

23 Jun '16

Hi, can I please get a review for this small change which fixes a code generation problem on ppc64: http://cr.openjdk.java.net/~simonis/webrevs/2016/8158260/ https://bugs.openjdk.java.net/browse/JDK-8158260 In the case where we access an unaligned address trough Unsafe, we could generate an illegal instruction because we didn't correctly specify the memory operand of some match rules. The fix is trivial. Although this change is ppc64-specific I think I need a sponsor because the change contains a new regression test which is supposed to run on all platforms. On platforms where Unsafe.unalignedAccess() will return false (e.g. Solaris/SPARC) this test will return immediately (and I've verified that it works). I've also added aarch64 to the list of recipients because on aarch64 Unsafe.unalignedAccess() is apparently supported and it would be nice if somebody could check that the new regression test is indeed working there. @Hiroshi, Gustavo: could you please verify that this change is enough to fix the initial problems you've observed when running Cassandra on Linux/ppc64? The changes from ppc64.ad should easily apply to the 8u-dev repository. Once we've got this into jdk9 I'll trigger a downport request to get the fix into jdk8 as well. Thank you and best regards, Volker

4 5

RFR: 8160006 Fix AArch64 after changes made by 8151661
by Andrew Dinn 22 Jun '16

22 Jun '16

The Fix: Please review the following webrev against hs-comp head which provides a patch to fix the AArch64 ad file after it is broken by JDK-8151661. http://cr.openjdk.java.net/~adinn/8160006/webrev.00/ n.b. The webrev also includes the changes for 8151661 (which has not yet been posted to hs-comp). Testing: Eyeballing of the code generated during a run of HelloWorld (-XX:-TieredCompilation -XX:+PrintOptoAssembly) shows it is generating cbxx and tbxx instructions as expected. regards, Andrew Dinn ----------- Senior Principal Software Engineer Red Hat UK Ltd Registered in England and Wales under Company Registration No. 03798903 Directors: Michael Cunningham, Michael ("Mike") O'Neill, Eric Shander

3 5