November 2016 - aarch64-port-dev

RFR: 8169697: aarch64: vectorized MLA instruction not generated for some test cases
by Ningsheng Jian 04 May '17

04 May '17

Hi, NEON vector MLA instructions can not be generated in some simple multiply-add cases. Bug: https://bugs.openjdk.java.net/browse/JDK-8169697 The following webrev contributed by Yang Zhang (yang.zhang(a)linaro.org) can resolve it. Webrev: http://cr.openjdk.java.net/~njian/8169697/webrev.00/ Please help to review it. To minimize impact, this patch only changes aarch64 specified code. Do you think this is OK for 9? If yes, do we need a FC Extension Request? In the mean time, Yang also has a more generic fix for this issue, which patches share code and could also fix this issue: http://cr.openjdk.java.net/~njian/8169697/webrev.share/ Which do you think is better? Both patches tested with fastdebug jtreg. Thanks, Ningsheng

5 21

RFR: AArch64: -XX:-UseOnStackReplacement does not work together with -XX:+TieredCompilation.
by Ningsheng Jian 21 Feb '17

21 Feb '17

Hi, Hotspot patch [1] introduces a test case hotspot/test/compiler/interpreter/DisableOSRTest.java which also exposes the same issue on aarch64. I.e. with -XX:-UseOnStackReplacement and -XX:+TieredCompilation options, there are still OSR compilations found from -XX:+PrintCompilation. On x86, the increment_mask_and_jump just jumps to the next instruction if backedge_counter_overflow is not generated. So there is no such issue - but is it intended? The following fix on AArch64 is to revert [2] to align with x86 code and assign the correct branch target based on the UseOnStackReplacement option. http://people.linaro.org/~ningsheng.jian/disable-osr/webrev.00/ Tested with jtreg. [1] http://hg.openjdk.java.net/jdk9/hs-comp/hotspot/rev/fd222df9f27c [2] http://hg.openjdk.java.net/aarch64-port/jdk8/hotspot/rev/18e5cbbe8abf

2 3

Fwd: Compact strings enablement - JTreg runs
by Stuart Monteith 30 Jan '17

30 Jan '17

Hello, I sent this to the wrong address by accident, and it hadn't bounced - the autocorrect kicked in this time. With a view to enable compact strings by default, I've run JTreg against a build from yesterday with "-XX:-CompactStrings" and "-XX:+CompactStrings". I get the following differences: 0: JTwork-compactoff pass: 5,840; fail: 1,793; error: 21; not run: 331 1: JTwork-compacton pass: 5,836; fail: 1,793; error: 25; not run: 331 0 1 Test fail pass com/sun/jdi/InterruptHangTest.java pass error java/awt/Dialog/CloseDialog/CloseDialogTest.java fail pass java/awt/Graphics2D/DrawString/DrawStringCrash.java pass error java/lang/instrument/PremainClass/NoPremainAgentTest.java pass fail java/rmi/activation/Activatable/restartCrashedService/RestartCrashedService.java pass fail java/rmi/server/RMISocketFactory/useSocketFactory/unicast/UseCustomSocketFactory.java error pass java/util/ResourceBundle/modules/visibility/visibility.sh pass fail java/util/concurrent/tck/JSR166TestCase.java pass error java/util/stream/boottest/java.base/java/util/stream/SpinedBufferTest.java fail pass java/util/zip/EntryCount64k.java pass error sun/security/provider/SecureRandom/StrongSecureRandom.java pass error tools/launcher/ArgFileSyntax.java 12 differences Ideally there would be 0 failures and errors in both, but I'll check to see what the differences were. Some of the names are suspicious, others - such as concurrency tests - look like they have the potential to have issues. AFAICT, this is the only changed needed to make compact strings the default: hotspot/src/cpu/aarch64/vm/globals_aarch64.hpp -- define_pd_global(bool, CompactStrings, false); ++ define_pd_global(bool, CompactStrings, true); hasNegatives - please find attached my most recent results with my hasNegatives intrinsic. The vertical axis is time (logarithmic) -lower is better. The horizontal axis is the number of characters scanned before has_negatives returns true. I'm trying to even-out the middle to lower side of the graph, as I expect has_negatives will trip either early, or late. Regards, Stuart

3 16

RFR: Backport patch for 8165673 to aarch64/jdk8u
by Felix Yang 09 Jan '17

09 Jan '17

Hi, I see the same issue (8165673) for aarch64/jdk8u repo, and I am trying to backport this patch: # HG changeset patch # User adinn # Date 1474964726 -3600 # Tue Sep 27 09:25:26 2016 +0100 # Node ID f96dfffcb4148c3615826adda611e80fe1c264f9 # Parent 2765f61021270b8e5d2954eb81b33e8311332f62 8165673: AArch64: Fix JNI floating point argument handling Reviewed-by: aph, adinn Contributed-by: ningsheng.jian(a)linaro.org Here are the link to the original jdk9 patch: http://hg.openjdk.java.net/jdk9/hs-comp/hotspot/rev/9cc82b204d20 The backport patch with some adaptations for the test case: http://cr.openjdk.java.net/~fyang/8165673-backport/webrev.01/ Tested with Jtreg using an aarch64 server build. OK to backport? As I don't have write permission of the icedtea branch ( http://icedtea.classpath.org/hg/icedtea7-forest/hotspot/) can someone do a backport for it please? Thanks for your help, Felix

4 6

RFR: JDK-8169177 Aarch64: SIGSEGV when "-XX:+ZeroTLAB" is specified along with GC options
by Kavitha Natarajan 15 Dec '16

15 Dec '16

Hi, The following are the jtreg test cases that fail with SIGSEGV on aarch64 when "-XX:+ZeroTLAB" is specified along with GC options: hotspot/test/compiler/stringopts/TestStringObjectInitialization.java hotspot/test/gc/TestSystemGC.java hotspot/test/gc/arguments/TestAlignmentToUseLargePages.java hotspot/test/gc/cms/TestBubbleUpRef.java hotspot/test/gc/metaspace/TestMetaspacePerfCounters.java hotspot/test/gc/parallel/TestDynShrinkHeap.java hotspot/test/gc/stress/TestGCOld.java Bug fix for JDK-8086053 <https://bugs.openjdk.java.net/browse/JDK-8086053> (Address inconsistencies regarding ZeroTLAB) fixes similar issue on x86 and sparc. This is now ported to aarch64 and the above test cases now pass on aarch64 as well. Below is the webrev for the changes: http://people.linaro.org/~kavitha.natarajan/8169177/webrev.00/ Can someone please review ? Thanks, Kavitha

3 12

Fireside chat - Thursday
by Stuart Monteith 01 Dec '16

01 Dec '16

Hello, This week we'll be having a fireside chat on Thursday at 1600 UTC, 1600 GMT, 1200 EST. Please note that daylight savings time are out of sync this week, but will be back to the usual offset after this weekend. In order to join in, please join the chat at Bluejeans here: https://bluejeans.com/791239268 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 $$$$. For the agenda Ed would like to discuss "JEP 297: Unified arm32/arm64 Port". http://openjdk.java.net/jeps/297 Best Regards, Stuart

3 3

RFR: 8170188: jtreg compiler/types/TestMeetIncompatibleInterfaceArrays.java causes JVM crash
by Sergey Nazarkin 30 Nov '16

30 Nov '16

Hi! please review the fix [1] to solve JVM crash when compiler/types/TestMeetIncompatibleInterfaceArrays.java test is executed. The crash happens at ANDS generation procedure since imm encoder fails to convert zero value. And it has to fail according ARMv8 arch ref manual. The patch detects invalid case and replace ANDS(Rd, Rn, imm) with ANDS(RD, Rn, ZeroReg) [1] http://cr.openjdk.java.net/~snazarki/8170188/ [2] https://bugs.openjdk.java.net/browse/JDK-8170188 Sergey

3 14

hg: aarch64-port/jdk8u/hotspot: 8170188: jtreg test compiler/types/TestMeetIncompatibleInterfaceArrays.java causes JVM crash
by adinn＠redhat.com 30 Nov '16

30 Nov '16

Changeset: fd2eea5dcdd9 Author: adinn Date: 2016-11-30 07:10 -0500 URL: http://hg.openjdk.java.net/aarch64-port/jdk8u/hotspot/rev/fd2eea5dcdd9 8170188: jtreg test compiler/types/TestMeetIncompatibleInterfaceArrays.java causes JVM crash Contributed-by: snazarki Reviewed-by: aph, adinn ! src/cpu/aarch64/vm/interp_masm_aarch64.cpp ! src/cpu/aarch64/vm/interp_masm_aarch64.hpp ! src/cpu/aarch64/vm/templateInterpreter_aarch64.cpp ! src/cpu/aarch64/vm/templateTable_aarch64.cpp

1 0

RFR(s) PPC64/s390x/aarch64: Poor StrictMath performance due to non-optimized compilation
by Gustavo Romero 29 Nov '16

29 Nov '16

Hi all, I'm re-sending due to JDK title update to include s390x and aarch64 archs. Could the following webrev be reviewed, please? webrev 1/2: http://cr.openjdk.java.net/~gromero/8170153/v2/ webrev 2/2: http://cr.openjdk.java.net/~gromero/8170153/v2/jdk/ bug: https://bugs.openjdk.java.net/browse/JDK-8170153 Thank you. Regards, Gustavo

4 7

RFR(XS): 8170470: superword may miss reductions
by Roland Westrelin 29 Nov '16

29 Nov '16

http://cr.openjdk.java.net/~roland/8170470/webrev.00/ This was discussed before on aarch64-port-dev. With the following method: public static int vectSumOfMulAdd1( int[] a, int[] b, int[] c, int[] d) { int total = 0; for (int i = 0; i < LENGTH; i++) { d[i] = (int)(a[i] * b[i] + c[i]); total += d[i]; } return total; } the main loop is not vectorized because the reduction is missed by the superword optimization. The result of the reduction is used by a control node (Return here) and the reduction is wrongly discarded. Roland.

1 0