September 2016 - aarch64-port-dev

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: AArch64: SEGV in stub code cipherBlockChaining_decryptAESCrypt
by Ningsheng Jian 13 Oct '16

13 Oct '16

Hi, Jtreg test jdk/test/com/sun/crypto/provider/Cipher/CTS/CTSMode.java failed with SIGSEGV on option "-Xcomp -XX:-TieredCompilation". The crash happens at stub code cipherBlockChaining_decryptAESCrypt. Checking the jdk source code CipherTextStealing.decryptFinal and its callee CipherBlockChaining.decrypt/implDecrypt, we can see that cipherLen which is passed to the stub code can be 0. The unexpected len_reg value makes the load from invalid address. The following patch could fix this issue: http://people.linaro.org/~ningsheng.jian/webrev/cbc-stub-fix/webrev.00/ It aligns with the Java code implementation and passed JTreg tests. To make code consistent, I also update the encrypt part. Could someone please help to take a look at it? Thanks, Ningsheng

4 8

Webrev of Oracle ARM & AARCH64 Sources
by Bob Vandette 03 Oct '16

03 Oct '16

I’m am please to announce that I have completed our internal reviews and can now open up the sources to our ARM 32 & 64 bit implementations of JDK9. Here is a webrev that includes a patch that can be applied on top of the (http://hg.openjdk.java.net/aarch32-port/jdk9-arm3264/ <http://hg.openjdk.java.net/aarch32-port/jdk9-arm3264/>) forest. http://cr.openjdk.java.net/~bobv/arm3264/webrev <http://cr.openjdk.java.net/~bobv/arm3264/webrev> Notes: 1. Counter to my initial email announcing the open sourcing effort, the pregenerated interpreter is not included in the provided patch. AOT is our long term solution for increased performance on Mobile and it was decided that we do not want to support the static interpreter beyond JDK 8. 2. In order to allow building the two different 64-bit ARM sources, I overloaded a new configure option —abi-profile to allow for the selection of the Oracle 64-bit ARM port. We need a better solution before this support can be integrated into the mainline. To use the Oracle sources for an aarch64 build, select —abi-profile=arm64. 3. The scripts provided below allows for the creation of the minimal, client and server VMs for the Oracle aarch64 build, however, the jvm.cfg file is not automatically updated during the build. To run a non server VM, this file will need to be updated. 4. In order to make it easier to keep the new open sources up to date with their closed counterparts in jdk9, I have added a comment in hotspot/src/cpu/arm/vm/vm_version_ext_arm.hpp which contains the mercurial revision that I last merged with. This will make it easier to produce patches to bring the new open files up to the latest version. /* ARM sources Merged up to hotspot/src/closed changeset 2316:b247a2ea70e4 */ Build Scripts: Here are a set of scripts that demonstrate how to build the three ARM configurations. We typically cross compile our ARM builds so these scripts will have to be adjusted in order to build natively on an ARM system. http://cr.openjdk.java.net/~bobv/arm3264/scripts/ <http://cr.openjdk.java.net/~bobv/arm3264/scripts/> aarch64.csh Builds the current open version of aarch64 binaries arm64.csh Builds the Oracle aarch64 binaries arm.csh Builds 32-bit ARM binaries My next step is to push this changeset into the jdk9-arm3264 forest assuming I achieve committer status for the aarch32 project this week. Bob Vandette

5 10

Re: [aarch64-port-dev ] Webrev of Oracle ARM & AARCH64 Sources
by Andrew Haley 29 Sep '16

29 Sep '16

On 28/09/16 20:22, Kostya Zolotnikov wrote: > > Not sure who told You about Azul's view. > For us it is not that clear what make sense for You. I'm not quite sure what you mean by this, but I can only go by what Azul representatives have posted here. If I've got anything wrong, I am happy to be corrected. Andrew.

3 6

Re: [aarch64-port-dev ] RFR: 8163014: Mysterious/wrong value for "long" frame local variable on 64-bit
by Ningsheng Jian 22 Sep '16

22 Sep '16

Hi Max, This patch breaks aarch64 build with: error: ‘wordsize’ was not declared in this scope I think it is a typo for "wordSize" at line below: 330 str(r, pre(esp, -wordsize)); Thanks, Ningsheng On 13 September 2016 at 00:06, Max Ockner <max.ockner(a)oracle.com> wrote: > New webrev: http://cr.openjdk.java.net/~mockner/8163014.hotspot.04/ > Comments below. > -Max > On 9/9/2016 1:54 PM, dean.long(a)oracle.com wrote: >> >> >> 614 movq(Address(rsp, 0), r); >> 615 movptr(Address(rsp, Interpreter::expr_offset_in_bytes(1)), >> NULL_WORD ); >> I wish these two looked more similar. I guess movq is the same as movprt, >> and >> Interpreter::expr_offset_in_bytes(0) >> could be used at 614? > > > Yes. I have made this change. >> >> >> 329 str(zr, pre(esp, -wordSize)); >> 330 str(r, pre(esp, -wordsize)); >> >> Do you want to use a single stp here? >> > The current patch is a working code suggestion from Andrew Dinn. If it is > important to change, I will see if I can build on aarch64 before submitting. > > >> dl >> >> On 9/9/16 9:51 AM, Max Ockner wrote: >>> >>> Oops. Here is version 2: >>> http://cr.openjdk.java.net/~mockner/8163014.hotspot.03/ >>> >>> Max >>> >>> On 9/8/2016 12:26 PM, Max Ockner wrote: >>>> >>>> Here is version 2 of this fix. >>>> - Added copyright to LocalLongHelper.java >>>> - Switched LocalLongTest.java to run with -Xint instead of -Xcomp, and >>>> cleaned up some copypaste garbage. >>>> - changed the test directory name from locallong to LocalLong. >>>> >>>> Reran test with -Xint. >>>> >>>> Thanks, >>>> Max >>>> >>>> On 9/7/2016 9:47 AM, Coleen Phillimore wrote: >>>>> >>>>> >>>>> Max, >>>>> >>>>> >>>>> http://cr.openjdk.java.net/~mockner/8163014.01/test/runtime/locallong/Local… >>>>> >>>>> There's a lot in this test, but I can't think of a different way to >>>>> inspect the stack to find out if the long unused slot is zeroed. This file >>>>> is missing a copyright, and I think the directory should be LocalLong (I >>>>> think our new convention of test directory names is capitalized). I think >>>>> we should keep the test in the hotspot repository even though it uses the >>>>> StackWalk API because otherwise it won't be run with hotspot changes on an >>>>> ad-hoc or nightly basis. >>>>> >>>>> >>>>> http://cr.openjdk.java.net/~mockner/8163014.01/test/runtime/locallong/Local… >>>>> >>>>> I thought the idea was to run this with -Xint not -Xcomp? >>>>> >>>>> The interpreter changes look good. >>>>> >>>>> Coleen >>>>> >>>>> On 9/6/16 5:33 PM, Max Ockner wrote: >>>>>> >>>>>> Hello, >>>>>> Please review this multi-platform fix for the stack walk API. >>>>>> >>>>>> Bug: https://bugs.openjdk.java.net/browse/JDK-8163014 >>>>>> Webrev: http://cr.openjdk.java.net/~mockner/8163014.01/ >>>>>> >>>>>> In 64 bits, long values can fit into a single slot, but two slots are >>>>>> still used. The high slot contains garbage. This normally wouldn't matter >>>>>> since it is never read from but the stack walk API expects to display useful >>>>>> information. This is an issue when displaying longs from local variables, so >>>>>> this means we can kill any garbage off by zeroing it when it is pushed to >>>>>> the stack in the previous frame. This solution zeroes the high byte of a >>>>>> long value when it is being pushed to the stack (in push_l). >>>>>> >>>>>> This applies to x86, aarch64, and sparc. This change does not apply to >>>>>> ppc, though the bug almost certainly does affect it. I have left ppc >>>>>> untouched since I don't have access to the hardware required to reproduce >>>>>> the bug and test the fix. >>>>>> >>>>>> I have adapted the reproducer from the bug into a test. It is curently >>>>>> sitting in runtime/locallong, but I believe there must be a better place for >>>>>> it. >>>>>> >>>>>> Thanks, >>>>>> Max >>>>> >>>>> >>>> >>> >> >

3 3

JCStress Failure -WCAS_WCAS
by Stuart Monteith 19 Sep '16

19 Sep '16

Hello, I've been testing aarch64 JDK 9, and have come across the following failures: org.openjdk.jcstress.tests.atomics.longs.AtomicLongPairwiseTests.WCAS_WCAS: Observed forbidden state: 1, 10 org.openjdk.jcstress.tests.atomics.integer.AtomicIntegerPairwiseTests.WCAS_WCAS: Observed forbidden state: 1, 10 org.openjdk.jcstress.tests.atomics.integer.AtomicIntegerPairwiseTests.WCAS_WCAS: Observed forbidden state: 1, 10 org.openjdk.jcstress.tests.atomics.booleans.AtomicBooleanPairwiseTests.WCAS_WCAS: Observed forbidden state: 0, 0 org.openjdk.jcstress.tests.atomics.longs.AtomicLongPairwiseTests.WCAS_WCAS: Observed forbidden state: 1, 10 org.openjdk.jcstress.tests.atomics.integer.AtomicIntegerArrayPairwiseTests.WCAS_WCAS: Observed forbidden state: 1, 10 org.openjdk.jcstress.tests.atomics.integer.AtomicIntegerPairwiseTests.WCAS_WCAS: Observed forbidden state: 1, 10 org.openjdk.jcstress.tests.atomics.booleans.AtomicBooleanPairwiseTests.WCAS_WCAS: Observed forbidden state: 0, 0 org.openjdk.jcstress.tests.atomics.integer.AtomicIntegerArrayPairwiseTests.WCAS_WCAS: Observed forbidden state: 1, 10 org.openjdk.jcstress.tests.atomics.longs.AtomicLongArrayPairwiseTests.WCAS_WCAS: Observed forbidden state: 1, 10 org.openjdk.jcstress.tests.atomics.integer.AtomicIntegerPairwiseTests.WCAS_WCAS: Observed forbidden state: 1, 10 org.openjdk.jcstress.tests.atomics.booleans.AtomicBooleanPairwiseTests.WCAS_WCAS: Observed forbidden state: 0, 0 org.openjdk.jcstress.tests.atomics.integer.AtomicIntegerArrayPairwiseTests.WCAS_WCAS: Observed forbidden state: 1, 10 org.openjdk.jcstress.tests.atomics.longs.AtomicLongArrayPairwiseTests.WCAS_WCAS: Observed forbidden state: 1, 10 These failures indicate that both actor's calls to weakCompareAndSet are failing. However, as the test cases don't test for that they are marked as "FORBIDDEN". I don't believe that that is correct. Because the compare and sets are weak, they will be subject to spurious failures, and that is what I'll be seeing. Would it be appropriate to set the testcases to something like the following? @Outcome(id = "1, 10", expect = Expect.ACCEPTABLE_SPEC, desc = "T1 & T2 spurious failure") and for boolean: @Outcome(id = "0, 0", expect = Expect.ACCEPTABLE, desc = "T1 & T2 failed spuriously") I might have submitted a patch, but currently I'm unable to build JCStress. This patch in langtools has cause the use of "-Xmodule:jdk.unsupported" in tests-chapter-1a/pom.xml to no longer work: 8164745: javac -Xmodule compiles the module in a way that reads the unnamed module Summary: Ensuring proper separation between named modules the unnamed module when using -Xmodule In addition, "weakCompareAndSetVolatile" has been changed to "weakCompareAndSetPlain" which requires more changes to jcstress. Best regards, Stuart

2 5

RFR: AArch64: Fix JNI floating point argument handling
by Ningsheng Jian 09 Sep '16

09 Sep '16

Hi, The jtreg test failure of hotspot/test/compiler/floatingpoint/Test15FloatJNIArgs.java is caused by incorrect floating point argument handling in JNI native wrapper. The following patch: http://people.linaro.org/~ningsheng.jian/jni-fix/webrev.00/ can fix this bug. I also updated the test case (and renamed to TestFloatJNIArgs.java), which exposes more issues in jni floating point args handling. (Need to update the fake bug-id in the test java source, as I don't have access right to JBS). Those issues can also be fixed by the patch. Could someone please help to review and process the patch? Thanks, Ningsheng

3 6