April 2015 - aarch64-port-dev

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

aarch64: jdk9: 8078245: fails to build from source
by Edward Nevill 05 May '15

05 May '15

Hi, The current jdk9 tip fails to build from source on aarch64 with the following error message /home/ed/build/1504/dev/build/linux-aarch64-normal-server-release/support/native/java.desktop/libsplashscreen/pngrutil.o: In function `png_init_filter_functions': /home/ed/build/1504/dev/jdk/src/java.desktop/share/native/libsplashscreen/libpng/pngrutil.c:3947: undefined reference to `png_init_filter_functions_neon' collect2: error: ld returned 1 exit status The following webrev gets it building again. http://cr.openjdk.java.net/~enevill/8078245/webrev.00/ Please review and if approved push. See comments below. Thanks, Ed. This was introduced at changeset 11769 changeset: 11769:cb75299d5933 user: azvegint date: Mon Jan 19 20:02:31 2015 +0300 files: src/java.desktop/share/native/libsplashscreen/libpng/CHANGES src/java.desktop/share/native/libsplashscreen/libpng/LICENSE src/java.desktop/share/native/libsplashscreen/libpng/README src/java.desktop/share/native/libsplashscreen/libpng/png.c src/java.desktop/share/native/libsplashscreen/libpng/png.h src/java.desktop/share/native/libsplashscreen/libpng/pngconf.h src/java.desktop/share/native/libsplashscreen/libpng/pngdebug.h src/java.desktop/share/native/libsplashscreen/libpng/pngerror.c src/java.desktop/share/native/libsplashscreen/libpng/pngget.c src/java.desktop/share/native/libsplashscreen/libpng/pnginfo.h src/java.desktop/share/native/libsplashscreen/libpng/pnglibconf.h src/java.desktop/share/native/libsplashscreen/libpng/pngmem.c src/java.desktop/share/native/libsplashscreen/libpng/pngpread.c src/java.desktop/share/native/libsplashscreen/libpng/pngpriv.h src/java.desktop/share/native/libsplashscreen/libpng/pngread.c src/java.desktop/share/native/libsplashscreen/libpng/pngrio.c src/java.desktop/share/native/libsplashscreen/libpng/pngrtran.c src/java.desktop/share/native/libsplashscreen/libpng/pngrutil.c src/java.desktop/share/native/libsplashscreen/libpng/pngset.c src/java.desktop/share/native/libsplashscreen/libpng/pngstruct.h src/java.desktop/share/native/libsplashscreen/libpng/pngtest.c src/java.desktop/share/native/libsplashscreen/libpng/pngtrans.c src/java.desktop/share/native/libsplashscreen/libpng/pngwio.c src/java.desktop/share/native/libsplashscreen/libpng/pngwrite.c src/java.desktop/share/native/libsplashscreen/libpng/pngwtran.c src/java.desktop/share/native/libsplashscreen/libpng/pngwutil.c description: 8069198: Upgrade image library Reviewed-by: ahgross, bae, mschoene, serb This changeset seems to introduce some ARM Neon optimisations, however I cannot seem to access the associated bug report JDK-8069198 as it seems I do not have suitable privileges to read the report. The problem is that it is also attempting to build this code for AARCH64 resulting in the above undefined symbol. The above webrev fixes this by ensuring that it only attempts to compile this code if defined(__arm__)

4 12

ZeroTLAB in aarch64 jdk7u
by Jonathan Springer 30 Apr '15

30 Apr '15

Hi all, AArch64 jdk7u tip is broken with -XX:+ZeroTLAB - it crashes on "hello world." I think this is probably the same bug as https://bugs.openjdk.java.net/browse/JDK-8073641 but that was fixed incidentally and the cause never identified. I realize 7u isn't getting any more attention, but does anyone happen to know what the problem might have been? Thanks, Jonathan -- Jonathan Springer | (212) 780-0527 x301 Reservoir Labs, Inc. | http://www.reservoir.com/

3 3

Java HotSpot Options for JIT generated native code disassembly support
by Claudio Fontana 29 Apr '15

29 Apr '15

Hello, what is the state of basic support for AArch64 of the +PrintAssembly, +PrintInterpreter, +PrintNativeMethods, ... options? Is the hsdis plugin already working for AArch64? Are some binaries available or should one rebuild it from source? Thank you, Claudio Fontana -- Claudio Fontana Server Virtualization Architect Huawei Technologies Duesseldorf GmbH Riesstraße 25 - 80992 München

3 3

Re: [aarch64-port-dev ] RFR: 8075930: AARCH64: Use FP Register in C2
by Edward Nevill 28 Apr '15

28 Apr '15

Hi Zoltán, Thanks for the review. I have updated the patch to take account of your comments. New patch at http://cr.openjdk.java.net/~enevill/8075930/webrev.02/ Could someone please review this patch and if approved push. See inline comments below. On Wed, 2015-03-25 at 14:28 +0100, Zoltán Majó wrote: > On 03/25/2015 02:02 PM, Edward Nevill wrote: > > Hi, > > > > The aarch64 C2 compiler makes no use of the FP register even though this register is saved on entry and restored on exit and is therefore always available for allocation. > > It seems to me that the C2 compiler currently saves the SP into FP on > method handle invokes. This functionality is encoded by > aarch64_enc_java_handle_call in aarch64.ad. C1 does the same (see usages > of FrameMap::method_handle_invoke_SP_save_opr()). So, this is an issue for C2 only, since my proposed patch does not affect register usage in C1, so C1 will continue to keep FP as unallocated. The change required for C2 is to let the register allocator know that FP will be killed by a methodhandle call. This is accomplished by the following change in aarch64.ad const RegMask Matcher::method_handle_invoke_SP_save_mask() { - return RegMask(); + return FP_REG_mask(); } > > Stack walking relies on having the SP saved into FP for method handle > invokes (e.g., in frame::adjust_unextended_sp()). > > Saving the SP into FP is not needed on some architectures (e.g., x86). > I'm currently working on an enhancement that disables saving the SP into > FP on x86 (see JDK-8068945). Maybe that could work for aarch64 as well. > > Does your change consider this aspect? Maybe running the tests in > jdk/test/java/lang/invoke/ could trigger some failures that are caused > by the FP not containing the SP of the caller of a method handle invocation. > I have run the jdk/test/java/lang/invoke tests both with and without the proposed patch. In bot cases 62 tests out of 62 passed. I have also rerun JTreg hotspot and langtools with the following results:- Before:- Hotspot: Test results: passed: 596; failed: 190; error: 26 Langtools: Test results: passed: 3,237; error: 9 After:- Hotspot: Test results: passed: 596; failed: 190; error: 26 Langtools: Test results: passed: 3,238; error: 8 All the best, Ed.

5 27

JDK9 Hotspot test failures (was RE: One other thing)
by Edward Nevill 28 Apr '15

28 Apr '15

Hi Alexander, I have moved this discussion to aarch-port-dev. On Wed, 2015-04-22 at 19:51 +0000, Alexeev, Alexander wrote: > Again no luck > > Test results: passed: 772; failed: 34; error: 22 > > hg clone http://hg.openjdk.java.net/jdk9/dev > hg clone http://hg.openjdk.java.net/jdk9/dev/hotspot > ... > + subfolders > Sorry, my bad. I am now seeing Test results: passed: 778; failed: 33; error: 1 Of the 33 failures most of these seem to be test failures rather than hotspot failures. For example, I believe I fixed all of these in jdk8 FAILED: compiler/stable/TestStableBoolean.java FAILED: compiler/stable/TestStableByte.java FAILED: compiler/stable/TestStableDouble.java FAILED: compiler/stable/TestStableChar.java FAILED: compiler/stable/TestStableLong.java FAILED: compiler/stable/TestStableInt.java FAILED: compiler/stable/TestStableShort.java FAILED: compiler/stable/TestStableObject.java FAILED: compiler/stable/TestStableFloat.java >From the jdk8 log changeset: 7554:68cf8e406ce5 user: Edward Nevill edward.nevill(a)linaro.org date: Wed Sep 24 12:56:10 2014 +0100 files: test/compiler/stable/StableConfiguration.java description: Fix failing TestStable tests However, it would seem these changes did not make it through to jdk9. If you feel like going through the remaining 33 failures and preparing a patch or patches for submission to jdk9 that would be most useful, otherwise I will add it to my todo list. For reference here is the list of test failures I am now seeing. The ones marked (*) I believe were fixed in jdk8. FAILED: compiler/codegen/7184394/TestAESMain.java FAILED: compiler/intrinsics/classcast/NullCheckDroppingsTest.java * FAILED: compiler/intrinsics/mathexact/sanity/MultiplyExactIntTest.java * FAILED: compiler/intrinsics/mathexact/sanity/IncrementExactIntTest.java * FAILED: compiler/intrinsics/mathexact/sanity/DecrementExactIntTest.java * FAILED: compiler/intrinsics/mathexact/sanity/AddExactIntTest.java * FAILED: compiler/intrinsics/mathexact/sanity/DecrementExactLongTest.java * FAILED: compiler/intrinsics/mathexact/sanity/MultiplyExactLongTest.java * FAILED: compiler/intrinsics/mathexact/sanity/NegateExactIntTest.java * FAILED: compiler/intrinsics/mathexact/sanity/IncrementExactLongTest.java * FAILED: compiler/intrinsics/mathexact/sanity/SubtractExactIntTest.java * FAILED: compiler/intrinsics/mathexact/sanity/AddExactLongTest.java * FAILED: compiler/intrinsics/mathexact/sanity/NegateExactLongTest.java * FAILED: compiler/intrinsics/mathexact/sanity/SubtractExactLongTest.java * FAILED: compiler/intrinsics/sha/cli/TestUseSHA256IntrinsicsOptionOnUnsupportedCPU.java * FAILED: compiler/intrinsics/sha/cli/TestUseSHAOptionOnUnsupportedCPU.java * FAILED: compiler/intrinsics/sha/cli/TestUseSHA1IntrinsicsOptionOnUnsupportedCPU.java * FAILED: compiler/intrinsics/sha/sanity/TestSHA1MultiBlockIntrinsics.java * FAILED: compiler/intrinsics/sha/sanity/TestSHA1Intrinsics.java * FAILED: compiler/intrinsics/sha/sanity/TestSHA256Intrinsics.java * FAILED: compiler/intrinsics/sha/sanity/TestSHA256MultiBlockIntrinsics.java * FAILED: compiler/stable/TestStableBoolean.java * FAILED: compiler/stable/TestStableByte.java * FAILED: compiler/stable/TestStableDouble.java * FAILED: compiler/stable/TestStableChar.java * FAILED: compiler/stable/TestStableLong.java * FAILED: compiler/stable/TestStableInt.java * FAILED: compiler/stable/TestStableShort.java * FAILED: compiler/stable/TestStableObject.java * FAILED: compiler/stable/TestStableFloat.java FAILED: compiler/whitebox/DeoptimizeFramesTest.java FAILED: runtime/CommandLine/TestVMOptions.java FAILED: testlibrary_tests/TestMutuallyExclusivePlatformPredicates.java

2 4

RFR: AArch64 -- patch to make volatile reads and stores use ldar/stlr
by Andrew Dinn 24 Apr '15

24 Apr '15

The following webrev is submitted for review (n.b. I am not an OpenJDK committer so the patch does not yet have an associated JIRA). http://cr.openjdk.java.net/~adinn/volatilefix/webrev.00 The patch modifies the AArch64 ad file rules to implement volatile loads and stores using load acquire (ldar<x>) and store release (stlr<x>) instructions. The memory barriers normally associated with volatile loads and stores are elided in these cases. http://cr.openjdk.java.net/~adinn/volatilefix/webrev.00/ Just to summarise what is happening here: The patch employs rule predicates to detect specific sequences of membar and memory nodes which are unique to volatile loads and stores. Two predicates control generation of normal vs acquiring loads and normal vs releasing stores. Three predicates control generation vs elision of memory barriers. The comments documenting these predicates provides a full explanation of which node sequences may arise as a result of a volatile load or store, how they can be detected and what alternative instruction encodings may be generated. The patch has successfully passed jcstress on two different AArch64 platforms. It has also successfully run javac and netbeans. regards, Andrew Dinn ----------- Senior Principal Software Engineer Red Hat UK Ltd Registered in UK and Wales under Company Registration No. 3798903 Directors: Michael Cunningham (USA), Matt Parson (USA), Charlie Peters (USA), Michael O'Neill (Ireland)

5 14

RFR: AARCH64: jdk9 fails to build from source
by Edward Nevill 22 Apr '15

22 Apr '15

Hi, The following webrev fixes a build failure in jdk9/aarch64 http://cr.openjdk.java.net/~enevill/8076488/webrev/ Issue report here https://bugs.openjdk.java.net/browse/JDK-8076488 Please review and push if appropriate. Thanks, Ed.

5 9

vectorisation experiment
by Edward Nevill 20 Apr '15

20 Apr '15

Hi, I have been experimenting with adding vectorisation to aarch64 jdk9. So I started with LoadVector, AddV, StoreVector and Replicate as in the attached patch. The following show a simple test case and the resultant asm output (I have highlighted the vector instructions with <<<<<) static void test_addv(long[] a0, long[] a1, long b) { for (int i = 0; i < a0.length; i+=1) { a0[i] = (long)(a1[i]+b); } } 0x000003ffad0ea070: sbfiz x10, x11, #3, #32 0x000003ffad0ea074: add x12, x2, x10 0x000003ffad0ea078: add x12, x12, #0x10 0x000003ffad0ea07c: ld1 {v17.16b}, [x12] <<<<< 0x000003ffad0ea080: sbfiz x12, x11, #3, #32 0x000003ffad0ea084: add x13, x2, x12 0x000003ffad0ea088: add v17.2d, v17.2d, v16.2d <<<<< 0x000003ffad0ea08c: add x14, x13, #0x20 0x000003ffad0ea090: ld1 {v18.16b}, [x14] <<<<< 0x000003ffad0ea094: add x10, x1, x10 0x000003ffad0ea098: add x10, x10, #0x10 0x000003ffad0ea09c: add v18.2d, v18.2d, v16.2d <<<<< 0x000003ffad0ea0a0: add x14, x13, #0x30 0x000003ffad0ea0a4: ld1 {v19.16b}, [x14] <<<<< 0x000003ffad0ea0a8: add x12, x1, x12 0x000003ffad0ea0ac: add x14, x12, #0x20 0x000003ffad0ea0b0: add x13, x13, #0x40 0x000003ffad0ea0b4: add v19.2d, v19.2d, v16.2d <<<<< 0x000003ffad0ea0b8: ld1 {v20.16b}, [x13] ;*laload <<<<< ; - TestLongVect::test_addv@16 (line 869) 0x000003ffad0ea0bc: st1 {v17.16b}, [x10] <<<<< 0x000003ffad0ea0c0: st1 {v18.16b}, [x14] <<<<< 0x000003ffad0ea0c4: add x10, x12, #0x30 0x000003ffad0ea0c8: st1 {v19.16b}, [x10] <<<<< 0x000003ffad0ea0cc: add v17.2d, v20.2d, v16.2d <<<<< 0x000003ffad0ea0d0: add x10, x12, #0x40 0x000003ffad0ea0d4: st1 {v17.16b}, [x10] ;*lastore<<<<< ; - TestLongVect::test_addv@19 (line 869) 0x000003ffad0ea0d8: add w11, w11, #0x8 ;*iinc ; - TestLongVect::test_addv@20 (line 868) 0x000003ffad0ea0dc: cmp w11, w16 0x000003ffad0ea0e0: b.lt 0x000003ffad0ea070 ;*if_icmpge Now at the moment this just using single vector register load/store. Eg. 0x000003ffad0ea090: ld1 {v18.16b}, [x14] .. 0x000003ffad0ea0bc: st1 {v17.16b}, [x10] <<<<< However aarch64 is capable of loading/storing up to 4 vector registers at a time. Eg. ld1 {v18,v19,v20,v21}, [x14] st1 {v17,v18,v19.v20}, [x10] In these instructions the 4 registers must be sequential (ie. {v(N), v(N+1), v(N+2), v(N+3) } It would obviously improve the above loop greatly if we could use these. My idea for doing this is to express this as a single 512 bit vector register. My question is how can I define this using 'reg_def' and 'reg_class' in aarch64.ad. I need some way to say to regalloc that if it allocates v(N) it must also allocate v(N+1), v(N+2), v(N+3). x86 has 256 bit XMM registers, eg. reg_def XMM0 ( SOC, SOC, Op_RegF, 0, xmm0->as_VMReg()); reg_def XMM0b( SOC, SOC, Op_RegF, 0, xmm0->as_VMReg()->next(1)); reg_def XMM0c( SOC, SOC, Op_RegF, 0, xmm0->as_VMReg()->next(2)); reg_def XMM0d( SOC, SOC, Op_RegF, 0, xmm0->as_VMReg()->next(3)); reg_def XMM0e( SOC, SOC, Op_RegF, 0, xmm0->as_VMReg()->next(4)); reg_def XMM0f( SOC, SOC, Op_RegF, 0, xmm0->as_VMReg()->next(5)); reg_def XMM0g( SOC, SOC, Op_RegF, 0, xmm0->as_VMReg()->next(6)); reg_def XMM0h( SOC, SOC, Op_RegF, 0, xmm0->as_VMReg()->next(7)); reg_class vectory_reg(XMM0, XMM0b, XMM0c, XMM0d, XMM0e, XMM0f, XMM0g, XMM0h, ... but this is not what I need. This is a single register 256 bits long, whereas I need a sort of virtual register which uses 4 physical registers. Thanks for any help, the documentation on this is not great! Ed.

2 1

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

17 Apr '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/107/sum… ------------------------------------------------------------------------------- client-release/hotspot ------------------------------------------------------------------------------- Build 0: aarch64/2014/nov/28 pass: 584; fail: 53; error: 1 Build 1: aarch64/2014/dec/05 pass: 584; fail: 53; error: 1 Build 2: aarch64/2014/dec/12 pass: 586; fail: 51; error: 1 Build 3: aarch64/2014/dec/16 pass: 585; fail: 52; error: 1 Build 4: aarch64/2015/jan/08 pass: 584; fail: 53; error: 1 Build 5: aarch64/2015/jan/09 pass: 584; fail: 53; error: 1 Build 6: aarch64/2015/feb/05 pass: 605; fail: 55; error: 2 Build 7: aarch64/2015/feb/13 pass: 605; fail: 55; error: 2 Build 8: aarch64/2015/mar/06 pass: 606; fail: 54; error: 2 Build 9: aarch64/2015/apr/17 pass: 605; fail: 55; error: 2 ------------------------------------------------------------------------------- client-release/jdk ------------------------------------------------------------------------------- Build 0: aarch64/2014/nov/28 pass: 5,324; fail: 216; error: 20 Build 1: aarch64/2014/dec/05 pass: 5,323; fail: 217; error: 20 Build 2: aarch64/2014/dec/12 pass: 5,334; fail: 206; error: 20 Build 3: aarch64/2014/dec/16 pass: 5,332; fail: 205; error: 23 Build 4: aarch64/2015/jan/08 pass: 5,327; fail: 211; error: 22 Build 5: aarch64/2015/jan/09 pass: 5,330; fail: 212; error: 18 Build 6: aarch64/2015/feb/05 pass: 5,347; fail: 222; error: 19 Build 7: aarch64/2015/feb/13 pass: 5,357; fail: 215; error: 16 Build 8: aarch64/2015/mar/06 pass: 5,354; fail: 216; error: 18 Build 9: aarch64/2015/apr/17 pass: 5,359; fail: 208; error: 24 ------------------------------------------------------------------------------- client-release/langtools ------------------------------------------------------------------------------- Build 0: aarch64/2014/nov/28 pass: 3,034; error: 14 Build 1: aarch64/2014/dec/05 pass: 3,037; error: 11 Build 2: aarch64/2014/dec/12 pass: 3,036; error: 12 Build 3: aarch64/2014/dec/16 pass: 3,039; error: 9 Build 4: aarch64/2015/jan/08 pass: 3,038; error: 10 Build 5: aarch64/2015/jan/09 pass: 3,037; error: 11 Build 6: aarch64/2015/feb/05 pass: 3,059; error: 14 Build 7: aarch64/2015/feb/13 pass: 3,064; error: 9 Build 8: aarch64/2015/mar/06 pass: 3,063; error: 10 Build 9: aarch64/2015/apr/17 pass: 3,063; error: 10 ------------------------------------------------------------------------------- server-release/hotspot ------------------------------------------------------------------------------- Build 0: aarch64/2014/nov/28 pass: 601; fail: 36; error: 1 Build 1: aarch64/2014/dec/05 pass: 599; fail: 38; error: 1 Build 2: aarch64/2014/dec/12 pass: 599; fail: 38; error: 1 Build 3: aarch64/2014/dec/16 pass: 602; fail: 35; error: 1 Build 4: aarch64/2015/jan/08 pass: 599; fail: 38; error: 1 Build 5: aarch64/2015/jan/09 pass: 599; fail: 38; error: 1 Build 6: aarch64/2015/feb/05 pass: 624; fail: 32; error: 6 Build 7: aarch64/2015/feb/13 pass: 626; fail: 32; error: 4 Build 8: aarch64/2015/mar/06 pass: 626; fail: 32; error: 4 Build 9: aarch64/2015/apr/17 pass: 625; fail: 32; error: 5 ------------------------------------------------------------------------------- server-release/jdk ------------------------------------------------------------------------------- Build 0: aarch64/2014/nov/28 pass: 5,116; fail: 424; error: 20 Build 1: aarch64/2014/dec/05 pass: 5,337; fail: 198; error: 25 Build 2: aarch64/2014/dec/12 pass: 5,318; fail: 218; error: 24 Build 3: aarch64/2014/dec/16 pass: 5,331; fail: 205; error: 24 Build 4: aarch64/2015/jan/08 pass: 5,330; fail: 202; error: 28 Build 5: aarch64/2015/jan/09 pass: 5,339; fail: 201; error: 20 Build 6: aarch64/2015/feb/05 pass: 5,349; fail: 209; error: 30 Build 7: aarch64/2015/feb/13 pass: 5,344; fail: 210; error: 34 Build 8: aarch64/2015/mar/06 pass: 5,348; fail: 207; error: 33 Build 9: aarch64/2015/apr/17 pass: 5,354; fail: 208; error: 29 ------------------------------------------------------------------------------- server-release/langtools ------------------------------------------------------------------------------- Build 0: aarch64/2014/nov/28 pass: 3,039; error: 9 Build 1: aarch64/2014/dec/05 pass: 3,041; error: 7 Build 2: aarch64/2014/dec/12 pass: 3,040; error: 8 Build 3: aarch64/2014/dec/16 pass: 3,036; error: 12 Build 4: aarch64/2015/jan/08 pass: 3,038; fail: 1; error: 9 Build 5: aarch64/2015/jan/09 pass: 3,038; error: 10 Build 6: aarch64/2015/feb/05 pass: 3,062; error: 11 Build 7: aarch64/2015/feb/13 pass: 3,064; error: 9 Build 8: aarch64/2015/mar/06 pass: 3,065; error: 8 Build 9: aarch64/2015/apr/17 pass: 3,063; error: 10 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.26x Relative performance: Server critical-jOPS (nc): 1.55x 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: 48.84, Server: 81.59 Client 48.84 / Client 2014-04-01 (43.00): 1.14x Server 81.59 / Server 2014-04-01 (71.00): 1.15x 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. 2014-11-28 pass rate: 11550/11550, results: http://openjdk.linaro.org/jcstress-nightly-runs/2014/332/results/ 2014-12-05 pass rate: 11550/11550, results: http://openjdk.linaro.org/jcstress-nightly-runs/2014/339/results/ 2014-12-12 pass rate: 11550/11550, results: http://openjdk.linaro.org/jcstress-nightly-runs/2014/346/results/ 2014-12-16 pass rate: 11550/11550, results: http://openjdk.linaro.org/jcstress-nightly-runs/2014/350/results/ 2015-01-08 pass rate: 11550/11550, results: http://openjdk.linaro.org/jcstress-nightly-runs/2015/008/results/ 2015-01-09 pass rate: 11550/11550, results: http://openjdk.linaro.org/jcstress-nightly-runs/2015/009/results/ 2015-02-05 pass rate: 11551/11551, results: http://openjdk.linaro.org/jcstress-nightly-runs/2015/036/results/ 2015-02-13 pass rate: 11551/11551, results: http://openjdk.linaro.org/jcstress-nightly-runs/2015/044/results/ 2015-03-06 pass rate: 11551/11551, results: http://openjdk.linaro.org/jcstress-nightly-runs/2015/065/results/ 2015-04-17 pass rate: 11555/11555, results: http://openjdk.linaro.org/jcstress-nightly-runs/2015/107/results/ For detailed information on the test output please refer to: http://openjdk.linaro.org/jcstress-nightly-runs/

1 0