November 2015 - aarch64-port-dev

RFR: aarch64: backports to JDK 7
by Edward Nevill 14 Dec '15

14 Dec '15

Hi, Please review the following backports to JDK 7 http://cr.openjdk.java.net/~enevill/jdk7_backports_1511/ Tested with jtreg hotspot & langtools. Results the same before and after. Hotspot: Test results: passed: 297; failed: 12; error: 2 Langtools: Test results: passed: 1,971; failed: 1; error: 2 Summary of the changesets below. Thanks, Ed. --- enevill@arm64:~/icedtea7-forest/hotspot$ hg outgoing comparing with ssh://enevill@icedtea.classpath.org/hg/icedtea7-forest/hotspot running ssh enevill(a)icedtea.classpath.org 'hg -R hg/icedtea7-forest/hotspot serve --stdio' searching for changes changeset: 6380:5b6efbae9fea user: aph date: Wed Nov 04 13:38:38 2015 +0100 files: src/share/vm/gc_implementation/parallelScavenge/psParallelCompact.hpp description: 8138966: Intermittent SEGV running ParallelGC Summary: Add necessary memory fences so that the parallel threads are unable to observe partially filled block tables. Reviewed-by: tschatzl changeset: 6381:c7679d143590 user: enevill date: Thu Nov 19 15:15:20 2015 +0000 files: src/cpu/aarch64/vm/assembler_aarch64.cpp description: 8143067: aarch64: guarantee failure in javac Summary: Fix adrp going out of range during code relocation Reviewed-by: aph, kvn changeset: 6382:eeb4a3ec4563 tag: tip user: hshi date: Tue Nov 24 09:02:26 2015 +0000 files: src/cpu/aarch64/vm/interp_masm_aarch64.cpp description: 8143285: aarch64: Missing load acquire when checking if ConstantPoolCacheEntry is resolved Reviewed-by: roland, aph ---

2 2

[RFR] openjdk aarch64: jdk/test/com/sun/net/httpserver/Test6a.java fails with --enable-unlimited-crypto
by Felix Yang 30 Nov '15

30 Nov '15

Hi, Could someone help review and sponsor this runtime fix for aarch64? Bug: https://bugs.openjdk.java.net/browse/JDK-8144201 Webrev: http://cr.openjdk.java.net/~fyang/8144201/webrev.00 The test fails on aarch64 platform using openjdk8/9 configured with --enable-unlimited-crypto. Reported error message: Execution failed: `main' threw exception: java.io.IOException: Error writing request body to server. And the test passes with -XX:TieredStopAtLevel=3 or -XX:-UseAESIntrinsics option. After narrowing down, I find the bug is caused by the _cipherBlockChaining_decryptAESCrypt StubRoutine. The proposed patch fixes an obvious typo in this StubRoutine. Passed JTreg regression test(using openjdk8 built with --enable-unlimited-crypto). Is it OK to push? Fei, Thanks for your help.

2 1

JTREG, SPECjbb2013 and Hadoop/Terasort results for OpenJDK 8 on AArch64
by Edward Nevill 30 Nov '15

30 Nov '15

This is a summary of the JTREG test results =========================================== The build and test results are cycled every 10 days. For detailed information on the test output please refer to: http://openjdk.linaro.org/openjdk8-jtreg-nightly-tests/summary/2015/331/sum… ------------------------------------------------------------------------------- client-release/hotspot ------------------------------------------------------------------------------- Build 0: aarch64/2015/jul/02 pass: 636; fail: 45; error: 5 Build 1: aarch64/2015/jul/08 pass: 636; fail: 45; error: 5 Build 2: aarch64/2015/jul/21 pass: 637; fail: 45; error: 5 Build 3: aarch64/2015/sep/04 pass: 636; fail: 46; error: 5 Build 4: aarch64/2015/sep/08 pass: 636; fail: 46; error: 5 Build 5: aarch64/2015/oct/22 pass: 637; fail: 45; error: 5 Build 6: aarch64/2015/oct/27 pass: 637; fail: 45; error: 5 Build 7: aarch64/2015/oct/29 pass: 637; fail: 45; error: 5 Build 8: aarch64/2015/nov/04 pass: 637; fail: 45; error: 5 Build 9: aarch64/2015/nov/27 pass: 637; fail: 45; error: 5 ------------------------------------------------------------------------------- client-release/jdk ------------------------------------------------------------------------------- Build 0: aarch64/2015/jul/02 pass: 5,499; fail: 230; error: 20 Build 1: aarch64/2015/jul/08 pass: 5,485; fail: 242; error: 22 Build 2: aarch64/2015/jul/21 pass: 5,502; fail: 233; error: 18 Build 3: aarch64/2015/sep/04 pass: 5,477; fail: 254; error: 22 Build 4: aarch64/2015/sep/08 pass: 5,477; fail: 254; error: 22 Build 5: aarch64/2015/oct/22 pass: 5,482; fail: 254; error: 17 Build 6: aarch64/2015/oct/27 pass: 5,472; fail: 259; error: 22 Build 7: aarch64/2015/oct/29 pass: 5,503; fail: 229; error: 21 Build 8: aarch64/2015/nov/04 pass: 5,503; fail: 228; error: 22 Build 9: aarch64/2015/nov/27 pass: 5,506; fail: 227; error: 20 ------------------------------------------------------------------------------- client-release/langtools ------------------------------------------------------------------------------- Build 0: aarch64/2015/jul/02 pass: 3,076; error: 15 Build 1: aarch64/2015/jul/08 pass: 3,080; error: 11 Build 2: aarch64/2015/jul/21 pass: 3,081; error: 10 Build 3: aarch64/2015/sep/04 pass: 3,078; error: 13 Build 4: aarch64/2015/sep/08 pass: 3,078; error: 13 Build 5: aarch64/2015/oct/22 pass: 3,077; error: 14 Build 6: aarch64/2015/oct/27 pass: 3,081; error: 10 Build 7: aarch64/2015/oct/29 pass: 3,079; error: 12 Build 8: aarch64/2015/nov/04 pass: 3,080; error: 11 Build 9: aarch64/2015/nov/27 pass: 3,078; error: 13 ------------------------------------------------------------------------------- server-release/hotspot ------------------------------------------------------------------------------- Build 0: aarch64/2015/jul/02 pass: 644; fail: 37; error: 5 Build 1: aarch64/2015/jul/08 pass: 644; fail: 37; error: 5 Build 2: aarch64/2015/jul/21 pass: 645; fail: 37; error: 5 Build 3: aarch64/2015/sep/04 pass: 645; fail: 37; error: 5 Build 4: aarch64/2015/sep/08 pass: 645; fail: 37; error: 5 Build 5: aarch64/2015/oct/22 pass: 644; fail: 38; error: 5 Build 6: aarch64/2015/oct/27 pass: 644; fail: 38; error: 5 Build 7: aarch64/2015/oct/29 pass: 645; fail: 37; error: 5 Build 8: aarch64/2015/nov/04 pass: 643; fail: 39; error: 5 Build 9: aarch64/2015/nov/27 pass: 643; fail: 38; error: 6 ------------------------------------------------------------------------------- server-release/jdk ------------------------------------------------------------------------------- Build 0: aarch64/2015/jul/02 pass: 5,510; fail: 215; error: 24 Build 1: aarch64/2015/jul/08 pass: 5,506; fail: 221; error: 22 Build 2: aarch64/2015/jul/21 pass: 5,512; fail: 217; error: 24 Build 3: aarch64/2015/sep/04 pass: 5,471; fail: 257; error: 25 Build 4: aarch64/2015/sep/08 pass: 5,471; fail: 257; error: 25 Build 5: aarch64/2015/oct/22 pass: 5,489; fail: 241; error: 23 Build 6: aarch64/2015/oct/27 pass: 5,495; fail: 234; error: 24 Build 7: aarch64/2015/oct/29 pass: 5,521; fail: 209; error: 23 Build 8: aarch64/2015/nov/04 pass: 5,509; fail: 222; error: 22 Build 9: aarch64/2015/nov/27 pass: 5,517; fail: 214; error: 22 ------------------------------------------------------------------------------- server-release/langtools ------------------------------------------------------------------------------- Build 0: aarch64/2015/jul/02 pass: 3,078; error: 13 Build 1: aarch64/2015/jul/08 pass: 3,083; error: 8 Build 2: aarch64/2015/jul/21 pass: 3,081; error: 10 Build 3: aarch64/2015/sep/04 pass: 3,078; error: 13 Build 4: aarch64/2015/sep/08 pass: 3,078; error: 13 Build 5: aarch64/2015/oct/22 pass: 3,082; fail: 2; error: 7 Build 6: aarch64/2015/oct/27 pass: 3,083; error: 8 Build 7: aarch64/2015/oct/29 pass: 3,081; error: 10 Build 8: aarch64/2015/nov/04 pass: 3,080; fail: 1; error: 10 Build 9: aarch64/2015/nov/27 pass: 3,079; error: 12 Previous results can be found here: http://openjdk.linaro.org/openjdk8-jtreg-nightly-tests/index.html SPECjbb2013 composite regression test completed =============================================== This test measures the relative performance of the server compiler running the SPECjbb2013 composite tests and compares the performance against the baseline performance of the server compiler taken on 2014-04-01. In accordance with [1], the SPECjbb2013 tests are run on a system which is not production ready and does not meet all the requirements for publishing compliant results. The numbers below shall be treated as non-compliant (nc) and are for experimental purposes only. Relative performance: Server max-jOPS (nc): 1.13x Relative performance: Server critical-jOPS (nc): 1.53x Details of the test setup and historical results may be found here: http://openjdk.linaro.org/SPECjbb2013-1.00-results/ [1] http://www.spec.org/fairuse.html#Academic Regression test Hadoop-Terasort completed ========================================= This test measures the performance of the server and client compilers running Hadoop sorting a 1GB file using Terasort and compares the performance against the baseline performance of the Zero interpreter and against the baseline performance of the client and server compilers on 2014-04-01. Relative performance: Zero: 1.0, Client: 49.18, Server: 89.9 Client 49.18 / Client 2014-04-01 (43.00): 1.14x Server 89.9 / Server 2014-04-01 (71.00): 1.27x Details of the test setup and historical results may be found here: http://openjdk.linaro.org/hadoop-terasort-benchmark-results/ This is a summary of the jcstress test results ============================================== The build and test results are cycled every 10 days. 2015-07-02 pass rate: 11556/11556, results: http://openjdk.linaro.org/jcstress-nightly-runs/2015/183/results/ 2015-07-08 pass rate: 11556/11556, results: http://openjdk.linaro.org/jcstress-nightly-runs/2015/189/results/ 2015-07-21 pass rate: 11556/11556, results: http://openjdk.linaro.org/jcstress-nightly-runs/2015/202/results/ 2015-09-04 pass rate: 11555/11556, results: http://openjdk.linaro.org/jcstress-nightly-runs/2015/247/results/ 2015-09-08 pass rate: 11555/11556, results: http://openjdk.linaro.org/jcstress-nightly-runs/2015/251/results/ 2015-10-22 pass rate: 11558/11558, results: http://openjdk.linaro.org/jcstress-nightly-runs/2015/295/results/ 2015-10-27 pass rate: 11558/11558, results: http://openjdk.linaro.org/jcstress-nightly-runs/2015/300/results/ 2015-10-29 pass rate: 11558/11558, results: http://openjdk.linaro.org/jcstress-nightly-runs/2015/302/results/ 2015-11-04 pass rate: 11558/11558, results: http://openjdk.linaro.org/jcstress-nightly-runs/2015/308/results/ 2015-11-27 pass rate: 11558/11558, results: http://openjdk.linaro.org/jcstress-nightly-runs/2015/331/results/ For detailed information on the test output please refer to: http://openjdk.linaro.org/jcstress-nightly-runs/

1 0

Re: [aarch64-port-dev ] 回复： RFR: JDK-8143584 Aarch64: Load constant pooltag and class status with load acquire
by Andrew Haley 26 Nov '15

26 Nov '15

On 11/26/2015 10:39 AM, hui.shi wrote: > Could I have an official reviewer and sponsor for this aarch64 runtime change? Pushed. Next time, please do an "hg commit" with proper comments before generating the webrev. Thanks, Andrew.

1 0

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: JDK-8143584 Aarch64: Load constant pool tag and class status with load acquire
by Hui Shi 26 Nov '15

26 Nov '15

Hi, Could someone help review and sponsor more runtime fix for aarch64? bug: https://bugs.openjdk.java.net/browse/JDK-8143584 webrev: http://cr.openjdk.java.net/~hshi/8143584/webrev/ This also fix some random crash in template interpreter. One of the crash test is langtools/test/tools/javac/TestLambdaToMethodStats.java. The symptom is: in checkcast, klass being checked is not valid klass pointer and trigger segmentation fault. The root cause is on aarch64 it miss load acquire when trying to read tag in constant pool before load resolved klass. Resolved class load might finish before tag load. Code for checkcast before fix 0x7f8409a5a0: add x8, x3, #0x4 0x7f8409a5a4: ldrb w1, [x8,x19] // load tag 0x7f8409a5a8: cmp x1, #0x7 __ cmp(r1, JVM_CONSTANT_Class); 0x7f8409a62c: mov x3, x0 0x7f8409a630: add x0, x2, x19, uxtx #3 0x7f8409a634: ldr x0, [x0,#80] 0x7f8409a638: ldr w19, [x3,#8] // load resolved class 0x7f8409a63c: eor x19, x19, #0x800000000 // x19 hold klass being checked Load resolved class might finish before load tag and read incorrect value. Fix is using load acquire when load tag. These tags are updated with release store in ConstantPool::release_tag_at_put (which uses OrderAccess::release_store), tags need be loaded with load acquire instruction ensure later resolved class load get correct klass. Fix is using load acquire when load tag and compare. After fix: 0x0000007f8009a6a4: add x8, x8, x19 0x0000007f8009a6a8: ldarb w1, [x8] 0x0000007f8009a6ac: cmp x1, #0x7 0x0000007f8009a6b0: b.eq 0x0000007f8009a730 …. 0x0000007f8009a730: mov x3, x0 0x0000007f8009a734: add x0, x2, x19, uxtx #3 0x0000007f8009a738: ldr x0, [x0,#80] 0x0000007f8009a73c: ldr w19, [x3,#8] 0x0000007f8009a740: eor x19, x19, #0x800000000 Checking similar places for aarch64 runtime, more places needs similar fix: 1. Instanceof is similar with checkcast 2. "ldc", similar with load resolved class in checkcast, need load acquire when loading tag in constant pool 3. "new" loads tag for resolved class. 4. "new" Loads and checks class initialized status, class init status update is guarded with orderaccess::storestore, need guarantee order between load class initialize status and load "instance_size in InstanceKlass". 5. C1 runtime checks if class initialize status when generate code for fast_new_instance_init_check_id, similar with "new". Regards Shi Hui

4 7

hg: aarch64-port/jdk8/hotspot: 4 new changesets
by edward.nevill＠gmail.com 26 Nov '15

26 Nov '15

Changeset: 3b837e8988b5 Author: aph Date: 2015-09-08 14:08 +0100 URL: http://hg.openjdk.java.net/aarch64-port/jdk8/hotspot/rev/3b837e8988b5 8135157: DMB elimination in AArch64 C2 synchronization implementation Summary: Reduce memory barrier usage in C2 fast lock and unlock. Reviewed-by: kvn Contributed-by: wei.tang(a)linaro.org, aph(a)redhat.com ! src/cpu/aarch64/vm/aarch64.ad Changeset: 85e9169ff89c Author: aph Date: 2015-11-04 13:38 +0100 URL: http://hg.openjdk.java.net/aarch64-port/jdk8/hotspot/rev/85e9169ff89c 8138966: Intermittent SEGV running ParallelGC Summary: Add necessary memory fences so that the parallel threads are unable to observe partially filled block tables. Reviewed-by: tschatzl ! src/share/vm/gc_implementation/parallelScavenge/psParallelCompact.hpp Changeset: 3b4d83989d8e Author: enevill Date: 2015-11-19 15:15 +0000 URL: http://hg.openjdk.java.net/aarch64-port/jdk8/hotspot/rev/3b4d83989d8e 8143067: aarch64: guarantee failure in javac Summary: Fix adrp going out of range during code relocation Reviewed-by: aph, kvn ! src/cpu/aarch64/vm/macroAssembler_aarch64.cpp Changeset: d74991e8f574 Author: hshi Date: 2015-11-24 09:02 +0000 URL: http://hg.openjdk.java.net/aarch64-port/jdk8/hotspot/rev/d74991e8f574 8143285: aarch64: Missing load acquire when checking if ConstantPoolCacheEntry is resolved Reviewed-by: roland, aph ! src/cpu/aarch64/vm/interp_masm_aarch64.cpp

1 0

RFR: Backports to jdk8
by Edward Nevill 25 Nov '15

25 Nov '15

Hi, Please review the following backports from JDK 9 to JDK 8. http://cr.openjdk.java.net/~enevill/jdk8_backports_1511 Tested with jtreg hotspot and langtools. Results the same before and after. Hotspot: Test results: passed: 674; failed: 17; error: 3 Langtools: Test results: passed: 3,091 Below is a summary of the changesets. Thanks, Ed. --- ed@arm64:~/jdk8/jdk8/hotspot$ hg outgoing comparing with ssh://enevill@hg.openjdk.java.net/aarch64-port/jdk8/hotspot running ssh enevill(a)hg.openjdk.java.net 'hg -R aarch64-port/jdk8/hotspot serve --stdio' searching for changes changeset: 8572:3b837e8988b5 user: aph date: Tue Sep 08 14:08:58 2015 +0100 files: src/cpu/aarch64/vm/aarch64.ad description: 8135157: DMB elimination in AArch64 C2 synchronization implementation Summary: Reduce memory barrier usage in C2 fast lock and unlock. Reviewed-by: kvn Contributed-by: wei.tang(a)linaro.org, aph(a)redhat.com changeset: 8573:85e9169ff89c user: aph date: Wed Nov 04 13:38:38 2015 +0100 files: src/share/vm/gc_implementation/parallelScavenge/psParallelCompact.hpp description: 8138966: Intermittent SEGV running ParallelGC Summary: Add necessary memory fences so that the parallel threads are unable to observe partially filled block tables. Reviewed-by: tschatzl changeset: 8574:3b4d83989d8e user: enevill date: Thu Nov 19 15:15:20 2015 +0000 files: src/cpu/aarch64/vm/macroAssembler_aarch64.cpp description: 8143067: aarch64: guarantee failure in javac Summary: Fix adrp going out of range during code relocation Reviewed-by: aph, kvn changeset: 8575:d74991e8f574 tag: tip user: hshi date: Tue Nov 24 09:02:26 2015 +0000 files: src/cpu/aarch64/vm/interp_masm_aarch64.cpp description: 8143285: aarch64: Missing load acquire when checking if ConstantPoolCacheEntry is resolved Reviewed-by: roland, aph ---

2 1

RFR(S): aarch64 Fix loading ConstantPoolCacheEntry._indices with load acquire
by Hui Shi 23 Nov '15

23 Nov '15

Hi, Could someone help review and sponsor this fix for aarch64 runtime? Bug: https://bugs.openjdk.java.net/browse/JDK-8143285 webrev: http://cr.openjdk.java.net/~hshi/8143285/webrev/ In InterpreterMacroAssembler::get_cache_and_index_and_bytecode_at_bcp, rewrite bytecode in ConstantPoolCacheEntry._indices is read with ldrw on aarch64. Following loads (for example ConstantPoolCacheEntry._flags and field offset) might finish before ConstantPoolCacheEntry._indices load and get unexpected values. ConstantPoolCacheEntry._indices is read and write with load acquire and store release in all other places. It also need load acquire here to guarantee read correct field offset and flags from ConstantPoolCacheEntry. getfield emplate interpreter code before fix 0x0000007f780a2aa4: ldrh w3, [x22,#1] 0x0000007f780a2aa8: add x2, x26, x3, lsl #5 0x0000007f780a2aac: ldr w19, [x2,#16] 0x0000007f780a2ab0: ubfx x19, x19, #16, #8 0x0000007f780a2ab4: cmp x19, #0xb4 0x0000007f780a2ab8: b.eq 0x0000007f780a2ba4 0x0000007f780a2ba4: ldr x19, [x2,#32] // read field offset, not ordered with rewrite byte code load 0x0000007f780a2ba8: ldr w0, [x2,#40] // read flags, not ordered with rewrite byte code load 0x0000007f780a2bac: ldr x4, [x20],#8 getfield template interpreter code after fix 0x0000007f900a2ba8: add x2, x26, x3, lsl #5 0x0000007f900a2bac: add x19, x2, #0x10 0x0000007f900a2bb0: ldar w19, [x19] 0x0000007f900a2bb4: ubfx x19, x19, #16, #8 0x0000007f900a2bb8: cmp x19, #0xb4 0x0000007f900a2bbc: b.eq 0x0000007f900a2ca8 0x0000007f780a2ba4: ldr x19, [x2,#32] // read offset, ordered with rewrite byte code load 0x0000007f780a2ba8: ldr w0, [x2,#40] // read flags，ordered with rewrite byte code load 0x0000007f780a2bac: ldr x4, [x20],#8 This problem causes template interpreter code for getfield gets wrong ConstantPoolCacheEntry._flags with uninitialized tos state. As uninitialized tos is "0" same with "btos", this is a little bit confusing when debug (at first uninitialized tos is 0 and it doesn’t trigger error in first execution of getfield, it triggers error in other thread when try to patch byte code with different value), is it possible to use some magic number here indicate the uninitialized "tos state" in _flags? For example 0xf, and it can trigger "bad state" error at first wrong palce. Regards Shi Hui

3 3

RFR: 8143067: aarch64: guarantee failure in javac (adrp out of range in relocation)
by Edward Nevill 20 Nov '15

20 Nov '15

Hi, Please review the following webrev http://cr.openjdk.java.net/~enevill/8143067/webrev JIRA Issuel: https://bugs.openjdk.java.net/browse/JDK-8143067 The issue is described in more detail in the JIRA issue but basically adrp instructions are becoming out of range during code relocation. This is happening with -Xmx4G (or greater). The problem is the existing code for adrp() does if (offset out of range) { generate other code to form address } else { generate adrp } Unfortunately this not work if the adrp subsequently becomes out of range due to code relocation, and this cannot be fixed up in a relocation because it will require more than 1 instruction. The solution I have adopted is to add a new method far_adrp() which must be used if the adrp may be out of range of a single adrp instruction. The existing adrp() has been modified to guarantee that the offset is in range. far_adrp() generates either adrp Rn, symbol nop if the symbol is initially within range or adrp Rn, <part symbol> ; fill in bits 0..31 in Rn mov Rn, <2nd part> << 32 ; fill in bits 32..47 If the symbol subsequently becomes out of range because of a code relocation the nop in the first form is rewritten as a movk in the 2nd form. Tested with jtreg hotspot and langtools Hotspot before: Test results: passed: 927; failed: 6; error: 11 Hotspot after: Test results: passed: 928; failed: 5; error: 11 Langtools before and after: Test results: passed: 3,326; error: 2 If have also tested it with jtreg/jdk to ensure there were no fatal errors and tested jtreg/hotspot with a fastdebug version to check the fix does not cause any assert failure. Thanks for your help, Ed.

2 1