From patrick at os.amperecomputing.com Mon Dec 2 03:18:58 2019 From: patrick at os.amperecomputing.com (Patrick Zhang OS) Date: Mon, 2 Dec 2019 03:18:58 +0000 Subject: [aarch64-port-dev ] RFR (trivial): 8234228: AArch64: Clean up redundant temp vars in generate_compare_long_string_different_encoding In-Reply-To: References: Message-ID: Ping... Please help review, thanks. Regards Patrick -----Original Message----- From: hotspot-compiler-dev On Behalf Of Patrick Zhang OS Sent: Friday, November 15, 2019 6:54 PM To: hotspot-compiler-dev at openjdk.java.net; aarch64-port-dev at openjdk.java.net Subject: RFR (trivial): 8234228: AArch64: Clean up redundant temp vars in generate_compare_long_string_different_encoding Hi Reviewers, This is a simple patch which cleans up some redundant temp vars and related instructions in generate_compare_long_string_different_encoding. JBS: https://bugs.openjdk.java.net/browse/JDK-8234228 Webrev: http://cr.openjdk.java.net/~qpzhang/8234228/webrev.01 In generate_compare_long_string_different_encoding, the two Register vars strU and strL were used to record the pointers of the last 4 characters for the final comparisons. strU has been no use since the latest code updates as the chars got pre-loaded (r12) by compare_string_16_x_LU early, and strL is redundant too since the pointer is available in r11. Cleaning up these can save two add, two temp vars, and replace two sub with mov. In addition, r10 in compare_string_16_x_LU is not used, cleaned the temp var too. Tested jtreg tier1, and hotspot runtime/compiler, no new failures found. Double checked with string intrinsics cases under [1], no regression found. Ran [2] CompareToBench LU/UL as performance check, no regression found, and slight gains with some input sizes [1] http://hg.openjdk.java.net/jdk/jdk/file/3df2bf731a87/test/hotspot/jtreg/compiler/intrinsics/string [2] http://cr.openjdk.java.net/~shade/density/string-density-bench.jar Regards Patrick From nick.gasson at arm.com Mon Dec 2 07:55:14 2019 From: nick.gasson at arm.com (Nick Gasson) Date: Mon, 2 Dec 2019 15:55:14 +0800 Subject: [aarch64-port-dev ] RFR(M): 8233743: AArch64: Make r27 conditionally allocatable In-Reply-To: <70f2fb20-f72d-07f6-b8ff-7d1e467c3c12@redhat.com> References: <93b1dff3-b760-e305-1422-d21178e9ed75@redhat.com> <28d32c06-9a8e-6f4b-8425-3f07a4fbfe82@redhat.com> <34081dab-0049-dda7-dead-3b2934f8c41b@arm.com> <97c0b309-e911-ff9f-4cea-b6f00bd4962d@redhat.com> <70f2fb20-f72d-07f6-b8ff-7d1e467c3c12@redhat.com> Message-ID: <450a3a82-3031-d988-ece1-cb1e37a74975@arm.com> On 29/11/2019 18:10, Andrew Haley wrote: >> How about we exit with a fatal error if we can't find a suitably aligned >> region? Then we can remove the code in decode_klass_non_null that uses >> R27 and this patch is much simpler. That code path is poorly tested at >> the moment so it seems risky to leave it in. With a hard error at least >> users will report it to us so we can fix it. > > That is starting to sound very attractive. With a 64-bit address space I'm > finding it very hard to imagine a scenario in which we don't find a > suitable address. I think AOT-compiled code would still be OK, because it > generates different code, but we'd have to do some testing. > There's another little wrinkle: even after updating the shared metaspace to use the search algorithm to find a 4G-aligned location, we can still end up with something like: CompressedKlassPointers::base() => 0x1100000000 CompressedKlassPointers::shift() => 3 (The shift is always set to LogKlassAlignmentInBytes when CDS is on.) Here we can't use EOR because 0x1100000000 doesn't fit in the immediate, and we can't use MOVK because the shift is non-zero. I think the solution is to adjust the algorithm to search in increments of (4 << LogKlassAlignmentInBytes)*G once we hit 32G (the point at which we can no longer use a zero base). Then we can decode like this: const uint64_t shifted_base = (uint64_t)CompressedKlassPointers::base() >> CompressedKlassPointers::shift(); guarantee((shifted_base & 0xffffffff) == 0, "compressed class base bad alignment"); if (dst != src) movw(dst, src); movk(dst, shifted_base >> 32, 32); if (CompressedKlassPointers::shift() != 0) { lsl(dst, dst, LogKlassAlignmentInBytes); } What do you think? I'll do some testing with AOT later. Thanks, Nick From Joshua.Zhu at arm.com Mon Dec 2 09:10:20 2019 From: Joshua.Zhu at arm.com (Joshua Zhu (Arm Technology China)) Date: Mon, 2 Dec 2019 09:10:20 +0000 Subject: [aarch64-port-dev ] 8233948: AArch64: Incorrect mapping between OptoReg and VMReg for high 64 bits of Vector Register In-Reply-To: References: Message-ID: Hi Andrew Dinn, > I think this is a good start but there is more work to do to clean up method > RegisterSaver::save_live_registers defined in file sharedRuntime_aarch64.cpp. > It would be good to do that clean up as part of this patch so it is all consistent. Thanks for your review! > 128 class FloatRegisterImpl: public AbstractRegisterImpl { > 129 public: > 130 enum { > 131 number_of_registers = 32, > 132 max_slots_per_register = 4, > save_slots_per_register = 2, > extra_save_slots_per_register = 2 > > The 2 new tags are needed because sharedRuntime_aarch64.cpp normally > only saves 2 slots per register but it occasionally needs to save all 4. Make sense. Bottom 64 bits of SVE vector register still overlaps with floating-point register, Therefore I will make extra_save_slots_per_register = max_slots_per_register - save_slots_per_register; so that we just need to improve the value of max_slots_per_register for SVE in future. > 607 const int FPUStateSizeInWords = 32 * 2; > > So, that can now be redefined as > > 607 const int FPUStateSizeInWords = > FloatRegisterImpl::number_of_registers * > FloatRegisterImpl::save_slots_per_register; > > We then need to redefine the code at lines 108 - 110 to use the enum values: > > 108 rfp_off = r0_off + > (RegisterImpl::number_of_registers - 2) * > RegisterImpl::max_slots_per_register, > 109 return_off = rfp_off + > RegisterImpl::max_slots_per_register, // slot for return address > 110 reg_save_size = return_off + > RegisterImpl::max_slots_per_register}; Thanks for your reminder! Make sense. > Finally, we can method edit save_live_registers at the point where it allows > space for the extra vector register content. That needs to be updated to use > the relevant constants: > > 116 if (save_vectors) { > 117 // Save upper half of vector registers > 118 int vect_words = FloatRegisterImpl::number_of_registers * > FloatRegisterImpl::extra_save_slots_per_register; > 119 additional_frame_words += vect_words; Here the computation of vect_words should be: int vect_words = FloatRegisterImpl::number_of_registers * FloatRegisterImpl::extra_save_slots_per_register / VMRegImpl::slots_per_word; > Could you prepare a new webrev with these extra changes in and check it is > ok? Yes, of course. I updated webrev according to your review comments. http://cr.openjdk.java.net/~jzhu/8233948/webrev.01/ > Also, could you report what testing you did before and after your change > (other than checking the dump output). You will probably need to repeat it to > ensure these extra changes are ok. Oh, Sorry for that. I did not mention my testing in my previous mail (My initial RFR mail is too long). I ran full jtreg tests without new failure introduced. I will re-run it against the new webrev and will let you know the results. Thanks again for your review. Best Regards, Joshua From aph at redhat.com Mon Dec 2 15:34:33 2019 From: aph at redhat.com (Andrew Haley) Date: Mon, 2 Dec 2019 10:34:33 -0500 Subject: [aarch64-port-dev ] RFR(M): 8233743: AArch64: Make r27 conditionally allocatable In-Reply-To: <450a3a82-3031-d988-ece1-cb1e37a74975@arm.com> References: <93b1dff3-b760-e305-1422-d21178e9ed75@redhat.com> <28d32c06-9a8e-6f4b-8425-3f07a4fbfe82@redhat.com> <34081dab-0049-dda7-dead-3b2934f8c41b@arm.com> <97c0b309-e911-ff9f-4cea-b6f00bd4962d@redhat.com> <70f2fb20-f72d-07f6-b8ff-7d1e467c3c12@redhat.com> <450a3a82-3031-d988-ece1-cb1e37a74975@arm.com> Message-ID: <7851d79d-5cff-05bc-9c52-b1f1bf3c175e@redhat.com> On 12/2/19 7:55 AM, Nick Gasson wrote: > On 29/11/2019 18:10, Andrew Haley wrote: >>> How about we exit with a fatal error if we can't find a suitably aligned >>> region? Then we can remove the code in decode_klass_non_null that uses >>> R27 and this patch is much simpler. That code path is poorly tested at >>> the moment so it seems risky to leave it in. With a hard error at least >>> users will report it to us so we can fix it. >> >> That is starting to sound very attractive. With a 64-bit address space I'm >> finding it very hard to imagine a scenario in which we don't find a >> suitable address. I think AOT-compiled code would still be OK, because it >> generates different code, but we'd have to do some testing. >> > > There's another little wrinkle: even after updating the shared metaspace > to use the search algorithm to find a 4G-aligned location, we can still > end up with something like: > > CompressedKlassPointers::base() => 0x1100000000 > CompressedKlassPointers::shift() => 3 > > (The shift is always set to LogKlassAlignmentInBytes when CDS is on.) I remember that. I don't know why; it's not much use to us on AArch64. > Here we can't use EOR because 0x1100000000 doesn't fit in the immediate, > and we can't use MOVK because the shift is non-zero. > > I think the solution is to adjust the algorithm to search in increments > of (4 << LogKlassAlignmentInBytes)*G once we hit 32G (the point at which > we can no longer use a zero base). Then we can decode like this: > > const uint64_t shifted_base = > (uint64_t)CompressedKlassPointers::base() >> > CompressedKlassPointers::shift(); > guarantee((shifted_base & 0xffffffff) == 0, "compressed class base > bad alignment"); > > if (dst != src) movw(dst, src); > movk(dst, shifted_base >> 32, 32); > > if (CompressedKlassPointers::shift() != 0) { > lsl(dst, dst, LogKlassAlignmentInBytes); > } > > What do you think? Could work, but can you also try disabling the shift with CDS? It doesn't do us much good and it bloats code. -- Andrew Haley (he/him) Java Platform Lead Engineer Red Hat UK Ltd. https://keybase.io/andrewhaley EAC8 43EB D3EF DB98 CC77 2FAD A5CD 6035 332F A671 From jianglizhou at google.com Mon Dec 2 16:05:37 2019 From: jianglizhou at google.com (Jiangli Zhou) Date: Mon, 2 Dec 2019 08:05:37 -0800 Subject: [aarch64-port-dev ] RFR(M): 8233743: AArch64: Make r27 conditionally allocatable In-Reply-To: <7851d79d-5cff-05bc-9c52-b1f1bf3c175e@redhat.com> References: <93b1dff3-b760-e305-1422-d21178e9ed75@redhat.com> <28d32c06-9a8e-6f4b-8425-3f07a4fbfe82@redhat.com> <34081dab-0049-dda7-dead-3b2934f8c41b@arm.com> <97c0b309-e911-ff9f-4cea-b6f00bd4962d@redhat.com> <70f2fb20-f72d-07f6-b8ff-7d1e467c3c12@redhat.com> <450a3a82-3031-d988-ece1-cb1e37a74975@arm.com> <7851d79d-5cff-05bc-9c52-b1f1bf3c175e@redhat.com> Message-ID: On Mon, Dec 2, 2019 at 7:34 AM Andrew Haley wrote: > > On 12/2/19 7:55 AM, Nick Gasson wrote: > > On 29/11/2019 18:10, Andrew Haley wrote: > >>> How about we exit with a fatal error if we can't find a suitably aligned > >>> region? Then we can remove the code in decode_klass_non_null that uses > >>> R27 and this patch is much simpler. That code path is poorly tested at > >>> the moment so it seems risky to leave it in. With a hard error at least > >>> users will report it to us so we can fix it. > >> > >> That is starting to sound very attractive. With a 64-bit address space I'm > >> finding it very hard to imagine a scenario in which we don't find a > >> suitable address. I think AOT-compiled code would still be OK, because it > >> generates different code, but we'd have to do some testing. > >> > > > > There's another little wrinkle: even after updating the shared metaspace > > to use the search algorithm to find a 4G-aligned location, we can still > > end up with something like: > > > > CompressedKlassPointers::base() => 0x1100000000 > > CompressedKlassPointers::shift() => 3 > > > > (The shift is always set to LogKlassAlignmentInBytes when CDS is on.) > > I remember that. I don't know why; it's not much use to us on AArch64. When CDS is enabled, the compressed klass encoding shift is set to LogKlassAlignmentInBytes with the intend for AOT compatibility. AOT requires LogKlassAlignmentInBytes (3) as the shift. Best, Jiangli > > > Here we can't use EOR because 0x1100000000 doesn't fit in the immediate, > > and we can't use MOVK because the shift is non-zero. > > > > I think the solution is to adjust the algorithm to search in increments > > of (4 << LogKlassAlignmentInBytes)*G once we hit 32G (the point at which > > we can no longer use a zero base). Then we can decode like this: > > > > const uint64_t shifted_base = > > (uint64_t)CompressedKlassPointers::base() >> > > CompressedKlassPointers::shift(); > > guarantee((shifted_base & 0xffffffff) == 0, "compressed class base > > bad alignment"); > > > > if (dst != src) movw(dst, src); > > movk(dst, shifted_base >> 32, 32); > > > > if (CompressedKlassPointers::shift() != 0) { > > lsl(dst, dst, LogKlassAlignmentInBytes); > > } > > > > What do you think? > > Could work, but can you also try disabling the shift with CDS? It doesn't do > us much good and it bloats code. > > -- > Andrew Haley (he/him) > Java Platform Lead Engineer > Red Hat UK Ltd. > https://keybase.io/andrewhaley > EAC8 43EB D3EF DB98 CC77 2FAD A5CD 6035 332F A671 > From ci_notify at linaro.org Tue Dec 3 06:49:34 2019 From: ci_notify at linaro.org (ci_notify at linaro.org) Date: Tue, 3 Dec 2019 06:49:34 +0000 (UTC) Subject: [aarch64-port-dev ] JTREG, JCStress, SPECjbb2015 and Hadoop/Terasort results for OpenJDK JDK on AArch64 Message-ID: <1856951625.3267.1575355775496.JavaMail.javamailuser@localhost> This is a summary of the JTREG test results =========================================== The build and test results are cycled every 15 days. For detailed information on the test output please refer to: http://openjdk.linaro.org/jdkX/openjdk-jtreg-nightly-tests/summary/2019/331/summary.html ------------------------------------------------------------------------------- client-release/hotspot ------------------------------------------------------------------------------- Build 0: aarch64/2018/oct/15 pass: 5,780; fail: 19; not run: 90 ------------------------------------------------------------------------------- client-release/jdk ------------------------------------------------------------------------------- Build 0: aarch64/2018/oct/15 pass: 8,495; fail: 670; error: 23 ------------------------------------------------------------------------------- client-release/langtools ------------------------------------------------------------------------------- Build 0: aarch64/2018/oct/15 pass: 3,970; fail: 5 ------------------------------------------------------------------------------- release/hotspot ------------------------------------------------------------------------------- Build 0: aarch64/2019/oct/23 pass: 5,760; fail: 1 Build 1: aarch64/2019/oct/28 pass: 5,766 Build 2: aarch64/2019/oct/30 pass: 5,768 Build 3: aarch64/2019/nov/01 pass: 5,768; fail: 1 Build 4: aarch64/2019/nov/04 pass: 5,769 Build 5: aarch64/2019/nov/06 pass: 5,766; fail: 2 Build 6: aarch64/2019/nov/08 pass: 5,761 Build 7: aarch64/2019/nov/11 pass: 5,762 Build 8: aarch64/2019/nov/13 pass: 5,764; fail: 1 Build 9: aarch64/2019/nov/15 pass: 5,750 Build 10: aarch64/2019/nov/18 pass: 5,750; fail: 1 Build 11: aarch64/2019/nov/20 pass: 5,752 Build 12: aarch64/2019/nov/22 pass: 5,752; fail: 1 Build 13: aarch64/2019/nov/25 pass: 5,752; fail: 1 Build 14: aarch64/2019/nov/27 pass: 5,752; fail: 2 1 fatal errors were detected; please follow the link above for more detail. ------------------------------------------------------------------------------- release/jdk ------------------------------------------------------------------------------- Build 0: aarch64/2019/oct/23 pass: 8,712; fail: 505; error: 18 Build 1: aarch64/2019/oct/28 pass: 8,711; fail: 509; error: 18 Build 2: aarch64/2019/oct/30 pass: 8,723; fail: 504; error: 19 Build 3: aarch64/2019/nov/01 pass: 8,774; fail: 506; error: 18 Build 4: aarch64/2019/nov/04 pass: 8,777; fail: 509; error: 17 Build 5: aarch64/2019/nov/06 pass: 8,775; fail: 507; error: 19 Build 6: aarch64/2019/nov/08 pass: 8,774; fail: 510; error: 17 Build 7: aarch64/2019/nov/11 pass: 8,777; fail: 509; error: 15 Build 8: aarch64/2019/nov/13 pass: 8,773; fail: 509; error: 21 Build 9: aarch64/2019/nov/15 pass: 8,756; fail: 511; error: 19 Build 10: aarch64/2019/nov/18 pass: 8,765; fail: 504; error: 18 Build 11: aarch64/2019/nov/20 pass: 8,768; fail: 504; error: 19 Build 12: aarch64/2019/nov/22 pass: 8,769; fail: 507; error: 18 Build 13: aarch64/2019/nov/25 pass: 8,775; fail: 509; error: 17 Build 14: aarch64/2019/nov/27 pass: 8,779; fail: 506; error: 22 5 fatal errors were detected; please follow the link above for more detail. ------------------------------------------------------------------------------- release/langtools ------------------------------------------------------------------------------- Build 0: aarch64/2019/oct/23 pass: 3,980 Build 1: aarch64/2019/oct/28 pass: 3,980 Build 2: aarch64/2019/oct/30 pass: 3,980 Build 3: aarch64/2019/nov/01 pass: 3,980 Build 4: aarch64/2019/nov/04 pass: 3,980 Build 5: aarch64/2019/nov/06 pass: 3,980 Build 6: aarch64/2019/nov/08 pass: 3,980 Build 7: aarch64/2019/nov/11 pass: 3,980 Build 8: aarch64/2019/nov/13 pass: 3,980 Build 9: aarch64/2019/nov/15 pass: 3,981 Build 10: aarch64/2019/nov/18 pass: 3,981 Build 11: aarch64/2019/nov/20 pass: 3,981 Build 12: aarch64/2019/nov/22 pass: 3,981 Build 13: aarch64/2019/nov/25 pass: 3,983 Build 14: aarch64/2019/nov/27 pass: 4,006 ------------------------------------------------------------------------------- server-release/hotspot ------------------------------------------------------------------------------- Build 0: aarch64/2018/oct/15 pass: 5,787; fail: 18; not run: 90 ------------------------------------------------------------------------------- server-release/jdk ------------------------------------------------------------------------------- Build 0: aarch64/2018/oct/15 pass: 8,476; fail: 686; error: 27 ------------------------------------------------------------------------------- server-release/langtools ------------------------------------------------------------------------------- Build 0: aarch64/2018/oct/15 pass: 3,970; fail: 5 Previous results can be found here: http://openjdk.linaro.org/jdkX/openjdk-jtreg-nightly-tests/index.html SPECjbb2015 composite regression test completed =============================================== This test measures the relative performance of the server compiler running the SPECjbb2015 composite tests and compares the performance against the baseline performance of the server compiler taken on 2016-11-21. In accordance with [1], the SPECjbb2015 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): 8.09x Relative performance: Server critical-jOPS (nc): 10.06x Details of the test setup and historical results may be found here: http://openjdk.linaro.org/jdkX/SPECjbb2015-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 server compiler on 2014-04-01. Relative performance: Zero: 1.0, Server: 204.57 Server 204.57 / Server 2014-04-01 (71.00): 2.88x Details of the test setup and historical results may be found here: http://openjdk.linaro.org/jdkX/hadoop-terasort-benchmark-results/ This is a summary of the jcstress test results ============================================== The build and test results are cycled every 15 days. 2019-10-22 pass rate: 10489/10489, results: http://openjdk.linaro.org/jdkX/jcstress-nightly-runs/2019/294/results/ 2019-10-23 pass rate: 10489/10489, results: http://openjdk.linaro.org/jdkX/jcstress-nightly-runs/2019/296/results/ 2019-10-29 pass rate: 10489/10489, results: http://openjdk.linaro.org/jdkX/jcstress-nightly-runs/2019/301/results/ 2019-10-31 pass rate: 10489/10489, results: http://openjdk.linaro.org/jdkX/jcstress-nightly-runs/2019/303/results/ 2019-11-02 pass rate: 10489/10489, results: http://openjdk.linaro.org/jdkX/jcstress-nightly-runs/2019/305/results/ 2019-11-05 pass rate: 10489/10489, results: http://openjdk.linaro.org/jdkX/jcstress-nightly-runs/2019/308/results/ 2019-11-07 pass rate: 10490/10490, results: http://openjdk.linaro.org/jdkX/jcstress-nightly-runs/2019/310/results/ 2019-11-12 pass rate: 10490/10490, results: http://openjdk.linaro.org/jdkX/jcstress-nightly-runs/2019/315/results/ 2019-11-14 pass rate: 10490/10490, results: http://openjdk.linaro.org/jdkX/jcstress-nightly-runs/2019/317/results/ 2019-11-16 pass rate: 10490/10490, results: http://openjdk.linaro.org/jdkX/jcstress-nightly-runs/2019/319/results/ 2019-11-19 pass rate: 10490/10490, results: http://openjdk.linaro.org/jdkX/jcstress-nightly-runs/2019/322/results/ 2019-11-21 pass rate: 10490/10490, results: http://openjdk.linaro.org/jdkX/jcstress-nightly-runs/2019/324/results/ 2019-11-23 pass rate: 10490/10490, results: http://openjdk.linaro.org/jdkX/jcstress-nightly-runs/2019/326/results/ 2019-11-26 pass rate: 10490/10490, results: http://openjdk.linaro.org/jdkX/jcstress-nightly-runs/2019/329/results/ 2019-12-03 pass rate: 10490/10490, results: http://openjdk.linaro.org/jdkX/jcstress-nightly-runs/2019/331/results/ For detailed information on the test output please refer to: http://openjdk.linaro.org/jdkX/jcstress-nightly-runs/ From nick.gasson at arm.com Tue Dec 3 07:43:19 2019 From: nick.gasson at arm.com (Nick Gasson) Date: Tue, 3 Dec 2019 15:43:19 +0800 Subject: [aarch64-port-dev ] RFR(M): 8233743: AArch64: Make r27 conditionally allocatable In-Reply-To: References: <93b1dff3-b760-e305-1422-d21178e9ed75@redhat.com> <28d32c06-9a8e-6f4b-8425-3f07a4fbfe82@redhat.com> <34081dab-0049-dda7-dead-3b2934f8c41b@arm.com> <97c0b309-e911-ff9f-4cea-b6f00bd4962d@redhat.com> <70f2fb20-f72d-07f6-b8ff-7d1e467c3c12@redhat.com> <450a3a82-3031-d988-ece1-cb1e37a74975@arm.com> <7851d79d-5cff-05bc-9c52-b1f1bf3c175e@redhat.com> Message-ID: >> > >> > CompressedKlassPointers::base() => 0x1100000000 >> > CompressedKlassPointers::shift() => 3 >> > >> > (The shift is always set to LogKlassAlignmentInBytes when CDS is on.) >> >> I remember that. I don't know why; it's not much use to us on AArch64. > > When CDS is enabled, the compressed klass encoding shift is set to > LogKlassAlignmentInBytes with the intend for AOT compatibility. AOT > requires LogKlassAlignmentInBytes (3) as the shift. > Yes, in AOTGraalHotSpotVMConfig.java we have: // AOT captures VM settings during compilation. For compressed oops this // presents a problem for the case when the VM selects a zero-shift mode // (i.e., when the heap is less than 4G). Compiling an AOT binary with // zero-shift limits its usability. As such we force the shift to be // always equal to alignment to avoid emitting zero-shift AOT code. CompressEncoding vmOopEncoding = super.getOopEncoding(); aotOopEncoding = new CompressEncoding(vmOopEncoding.getBase(), logMinObjAlignment()); CompressEncoding vmKlassEncoding = super.getKlassEncoding(); aotKlassEncoding = new CompressEncoding(vmKlassEncoding.getBase(), logKlassAlignment); I get why AOT needs to set the shift for compressed OOPs, but for compressed class pointers the maximum class space size is 3G so the shift is only useful to allow a zero base. For AOT+CDS the default class space load address is 0x800000000 (32G) which is above the limit where a zero base is possible. So I think it would be better if AOT and CDS used a zero shift by default, as on AArch64 and X86 at least, we generate less efficient code when both the shift and base are non-zero. Using logKlassAlignment above works well for non-CDS, as it allows the class space to mapped at a low address with zero base. Maybe aotKlassEncoding could be set from the current VM settings instead? Thanks, Nick From tobias.hartmann at oracle.com Tue Dec 3 08:18:22 2019 From: tobias.hartmann at oracle.com (Tobias Hartmann) Date: Tue, 3 Dec 2019 09:18:22 +0100 Subject: [aarch64-port-dev ] RFR(S): 8234791: Fix Client VM build for x86_64 and AArch64 In-Reply-To: <0b33fa95-ff15-b628-1891-f990f239e60f@oracle.com> References: <0b33fa95-ff15-b628-1891-f990f239e60f@oracle.com> Message-ID: Hi, this looks good to me. Best regards, Tobias On 30.11.19 02:02, Ioi Lam wrote: > Hi Pengfei, > > I have cc-ed hotspot-compiler-dev at openjdk.java.net. > > Please do not push the patch until someone from hotspot-compiler-dev has looked at it. > > Many people are away due to Thanksgiving in the US. > > Thanks > - Ioi > > On 11/28/19 7:56 PM, Pengfei Li (Arm Technology China) wrote: >> Hi, >> >> Please help review this small fix for 64-bit client build. >> >> Webrev: http://cr.openjdk.java.net/~pli/rfr/8234791/webrev.00/ >> JBS: https://bugs.openjdk.java.net/browse/JDK-8234791 >> >> Current 64-bit client VM build fails because errors occurred in dumping >> the CDS archive. In JDK 12, we enabled "Default CDS Archives"[1] which >> runs "java -Xshare:dump" after linking the JDK image. But for Client VM >> build on 64-bit platforms, the ergonomic flag UseCompressedOops is not >> set.[2] This leads to VM exits in checking the flags for dumping the >> shared archive.[3] >> >> This change removes the "#if defined" macro to make shared archive dump >> successful in 64-bit client build. By tracking the history of the macro, >> I found it is initially added as "#ifndef COMPILER1"[4] 10 years ago >> when C1 did not have a good support of compressed oops and modified to >> current shape[5] in the implementation of tiered compilation. It should >> be safe to be removed today. >> >> This patch also fixes another client build issue on AArch64. >> >> [1] http://openjdk.java.net/jeps/341 >> [2] >> http://hg.openjdk.java.net/jdk/jdk/file/981a55672786/src/hotspot/share/runtime/arguments.cpp#l1694 >> [3] >> http://hg.openjdk.java.net/jdk/jdk/file/981a55672786/src/hotspot/share/runtime/arguments.cpp#l3551 >> [4] http://hg.openjdk.java.net/jdk8/jdk8/hotspot/rev/323bd24c6520#l11.7 >> [5] http://hg.openjdk.java.net/jdk8/jdk8/hotspot/rev/d5d065957597#l86.56 >> >> -- >> Thanks, >> Pengfei >> > From Joshua.Zhu at arm.com Tue Dec 3 12:26:15 2019 From: Joshua.Zhu at arm.com (Joshua Zhu (Arm Technology China)) Date: Tue, 3 Dec 2019 12:26:15 +0000 Subject: [aarch64-port-dev ] 8233948: AArch64: Incorrect mapping between OptoReg and VMReg for high 64 bits of Vector Register In-Reply-To: References: Message-ID: Hi Andrew Dinn, > > Could you prepare a new webrev with these extra changes in and check > > it is ok? > > Yes, of course. I updated webrev according to your review comments. > http://cr.openjdk.java.net/~jzhu/8233948/webrev.01/ > > Also, could you report what testing you did before and after your > > change (other than checking the dump output). You will probably need > > to repeat it to ensure these extra changes are ok. > > Oh, Sorry for that. I did not mention my testing in my previous mail (My > initial RFR mail is too long). > I ran full jtreg tests without new failure introduced. > I will re-run it against the new webrev and will let you know the results. > Thanks again for your review. Testing: Passed hotspot_all_no_apps, jdk_core and langtools:tier1 without new failure introduced. Please let me know if any comments. Thanks! Best Regards, Joshua From Pengfei.Li at arm.com Wed Dec 4 06:25:30 2019 From: Pengfei.Li at arm.com (Pengfei Li (Arm Technology China)) Date: Wed, 4 Dec 2019 06:25:30 +0000 Subject: [aarch64-port-dev ] RFR(S): 8234791: Fix Client VM build for x86_64 and AArch64 In-Reply-To: References: <0b33fa95-ff15-b628-1891-f990f239e60f@oracle.com> Message-ID: Thanks Tobias. Could anyone help push this? It's now reviewed by adinn, aph and thartmann. > Hi, > > this looks good to me. > > Best regards, > Tobias > > On 30.11.19 02:02, Ioi Lam wrote: > > Hi Pengfei, > > > > I have cc-ed hotspot-compiler-dev at openjdk.java.net. > > > > Please do not push the patch until someone from hotspot-compiler-dev > has looked at it. > > > > Many people are away due to Thanksgiving in the US. > > > > Thanks > > - Ioi > > > > On 11/28/19 7:56 PM, Pengfei Li (Arm Technology China) wrote: > >> Hi, > >> > >> Please help review this small fix for 64-bit client build. > >> > >> Webrev: http://cr.openjdk.java.net/~pli/rfr/8234791/webrev.00/ > >> JBS: https://bugs.openjdk.java.net/browse/JDK-8234791 > >> > >> Current 64-bit client VM build fails because errors occurred in > >> dumping the CDS archive. In JDK 12, we enabled "Default CDS > >> Archives"[1] which runs "java -Xshare:dump" after linking the JDK > >> image. But for Client VM build on 64-bit platforms, the ergonomic > >> flag UseCompressedOops is not set.[2] This leads to VM exits in > >> checking the flags for dumping the shared archive.[3] > >> > >> This change removes the "#if defined" macro to make shared archive > >> dump successful in 64-bit client build. By tracking the history of > >> the macro, I found it is initially added as "#ifndef COMPILER1"[4] 10 > >> years ago when C1 did not have a good support of compressed oops and > >> modified to current shape[5] in the implementation of tiered > >> compilation. It should be safe to be removed today. > >> > >> This patch also fixes another client build issue on AArch64. > >> > >> [1] http://openjdk.java.net/jeps/341 > >> [2] > >> http://hg.openjdk.java.net/jdk/jdk/file/981a55672786/src/hotspot/shar > >> e/runtime/arguments.cpp#l1694 > >> [3] > >> http://hg.openjdk.java.net/jdk/jdk/file/981a55672786/src/hotspot/shar > >> e/runtime/arguments.cpp#l3551 [4] > >> http://hg.openjdk.java.net/jdk8/jdk8/hotspot/rev/323bd24c6520#l11.7 > >> [5] > >> http://hg.openjdk.java.net/jdk8/jdk8/hotspot/rev/d5d065957597#l86.56 -- Thanks, Pengfei From tobias.hartmann at oracle.com Wed Dec 4 07:09:45 2019 From: tobias.hartmann at oracle.com (Tobias Hartmann) Date: Wed, 4 Dec 2019 08:09:45 +0100 Subject: [aarch64-port-dev ] RFR(S): 8234791: Fix Client VM build for x86_64 and AArch64 In-Reply-To: References: <0b33fa95-ff15-b628-1891-f990f239e60f@oracle.com> Message-ID: <8315aeca-f0cb-b41e-782a-28e545772d09@oracle.com> On 04.12.19 07:25, Pengfei Li (Arm Technology China) wrote: > Thanks Tobias. Could anyone help push this? It's now reviewed by adinn, aph and thartmann. Sure, pushed. Best regards, Tobias From gnu.andrew at redhat.com Wed Dec 4 15:31:02 2019 From: gnu.andrew at redhat.com (Andrew Hughes) Date: Wed, 4 Dec 2019 10:31:02 -0500 Subject: [aarch64-port-dev ] [RFR] [8u] 8u242-b01 Upstream Sync In-Reply-To: <646b15f6-a7bc-b5c5-a502-83fb3df9f54d@redhat.com> References: <646b15f6-a7bc-b5c5-a502-83fb3df9f54d@redhat.com> Message-ID: On 27/11/2019 00:31, Andrew John Hughes wrote: > Webrevs: https://cr.openjdk.java.net/~andrew/shenandoah-8/u242-b01/ > > Merge changesets: > > http://cr.openjdk.java.net/~andrew/shenandoah-8/u242-b01/corba/merge.changeset > http://cr.openjdk.java.net/~andrew/shenandoah-8/u242-b01/jaxp/merge.changeset > http://cr.openjdk.java.net/~andrew/shenandoah-8/u242-b01/jaxws/merge.changeset > http://cr.openjdk.java.net/~andrew/shenandoah-8/u242-b01/jdk/merge.changeset > http://cr.openjdk.java.net/~andrew/shenandoah-8/u242-b01/hotspot/merge.changeset > http://cr.openjdk.java.net/~andrew/shenandoah-8/u242-b01/langtools/merge.changeset > http://cr.openjdk.java.net/~andrew/shenandoah-8/u242-b01/nashorn/merge.changeset > http://cr.openjdk.java.net/~andrew/shenandoah-8/u242-b01/root/merge.changeset > > Changes in aarch64-shenandoah-jdk8u242-b01: > - S8010500: [parfait] Possible null pointer dereference at > hotspot/src/share/vm/opto/loopnode.hpp > - S8067429: java.lang.VerifyError: Inconsistent stackmap frames at > branch target > - S8073154: NULL-pointer dereferencing in LIR_OpProfileType::print_instr > - S8077707: jdk9 b58 cannot run any graphical application on Win 8 > with JAWS running > - S8132249: Clean up JAB debugging code > - S8133951: Zero interpreter asserts in stubRoutines.cpp > - S8134739: compiler/loopopts/superword/TestVectorizationWithInvariant > crashes in loop opts > - S8209835: Aarch64: elide barriers on all volatile operations > - S8212071: Need to set the FreeType LCD Filter to reduce fringing. > - S8230238: Add another regression test for JDK-8134739 > - S8230813: Add JDK-8010500 to > compiler/loopopts/superword/TestFuzzPreLoop.java bug list > - S8231398: Add time tracing for gc log rotation at safepoint cleanup > - S8231988: Unexpected test result caused by C2 > IdealLoopTree::do_remove_empty_loop > > Main issues of note: > * 8209835 is already upstream but is part of this tag. > * 8073154 change to src/share/vm/c1/c1_LIR.cpp was already included in > an earlier form as part of "Implement type profiling in C1." [0]. Merge > conflict was resolve to use the 8u upstream version. > > diffstat for root > b/.hgtags | 3 +++ > 1 file changed, 3 insertions(+) > > diffstat for corba > b/.hgtags | 3 +++ > 1 file changed, 3 insertions(+) > > diffstat for jaxp > b/.hgtags | 3 +++ > 1 file changed, 3 insertions(+) > > diffstat for jaxws > b/.hgtags | 3 +++ > 1 file changed, 3 insertions(+) > > diffstat for langtools > b/.hgtags | 3 > b/src/share/classes/com/sun/tools/javac/jvm/Gen.java | 19 ++- > b/test/tools/javac/BranchToFewerDefines.java | 111 > +++++++++++++++++++ > 3 files changed, 128 insertions(+), 5 deletions(-) > > diffstat for nashorn > b/.hgtags | 3 +++ > 1 file changed, 3 insertions(+) > > diffstat for jdk > b/.hgtags | 3 > b/src/share/native/sun/font/freetypeScaler.c | 3 > b/src/windows/native/sun/bridge/AccessBridgeATInstance.cpp | 2 > b/src/windows/native/sun/bridge/AccessBridgeJavaEntryPoints.cpp | 2 > b/src/windows/native/sun/bridge/AccessBridgeJavaVMInstance.cpp | 2 > b/src/windows/native/sun/bridge/AccessBridgeWindowsEntryPoints.cpp | 1 > b/src/windows/native/sun/bridge/JavaAccessBridge.cpp | > 51 ++-------- > b/src/windows/native/sun/bridge/JavaAccessBridge.h | 2 > b/src/windows/native/sun/bridge/WinAccessBridge.cpp | 4 > 9 files changed, 26 insertions(+), 44 deletions(-) > > diffstat for hotspot > b/.hgtags | 3 > b/src/share/vm/c1/c1_LIR.cpp | 8 - > b/src/share/vm/opto/loopTransform.cpp | 9 + > b/src/share/vm/opto/loopnode.hpp | 1 > b/src/share/vm/opto/superword.cpp | 26 +++- > b/src/share/vm/runtime/safepoint.cpp | 1 > b/src/share/vm/runtime/stubRoutines.cpp | 4 > b/test/compiler/loopopts/TestRemoveEmptyLoop.java | 53 +++++++++ > b/test/compiler/loopopts/superword/TestFuzzPreLoop.java | 65 +++++++++++ > b/test/compiler/print/TestProfileReturnTypePrinting.java | 68 +++++++++++ > b/test/runtime/RedefineTests/test8178870.sh | 87 > +++++++++++++++ > 11 files changed, 312 insertions(+), 13 deletions(-) > > Successfully built on x86, x86_64, s390, s390x, ppc, ppc64, ppc64le & > aarch64. > > Ok to push? > > [0] > https://hg.openjdk.java.net/aarch64-port/jdk8u-shenandoah/hotspot/rev/050fe4f6976ab67316 > > Thanks, > Ping? Thanks, -- Andrew :) Senior Free Java Software Engineer Red Hat, Inc. (http://www.redhat.com) PGP Key: ed25519/0xCFDA0F9B35964222 (hkp://keys.gnupg.net) Fingerprint = 5132 579D D154 0ED2 3E04 C5A0 CFDA 0F9B 3596 4222 From ci_notify at linaro.org Wed Dec 4 19:13:27 2019 From: ci_notify at linaro.org (ci_notify at linaro.org) Date: Wed, 4 Dec 2019 19:13:27 +0000 (UTC) Subject: [aarch64-port-dev ] JTREG, JCStress, SPECjbb2015 and Hadoop/Terasort results for OpenJDK JDK on AArch64 Message-ID: <2111478562.3426.1575486807841.JavaMail.javamailuser@localhost> This is a summary of the JTREG test results =========================================== The build and test results are cycled every 15 days. For detailed information on the test output please refer to: http://openjdk.linaro.org/jdkX/openjdk-jtreg-nightly-tests/summary/2019/333/summary.html ------------------------------------------------------------------------------- client-release/hotspot ------------------------------------------------------------------------------- Build 0: aarch64/2018/oct/15 pass: 5,780; fail: 19; not run: 90 ------------------------------------------------------------------------------- client-release/jdk ------------------------------------------------------------------------------- Build 0: aarch64/2018/oct/15 pass: 8,495; fail: 670; error: 23 ------------------------------------------------------------------------------- client-release/langtools ------------------------------------------------------------------------------- Build 0: aarch64/2018/oct/15 pass: 3,970; fail: 5 ------------------------------------------------------------------------------- release/hotspot ------------------------------------------------------------------------------- Build 0: aarch64/2019/oct/28 pass: 5,766 Build 1: aarch64/2019/oct/30 pass: 5,768 Build 2: aarch64/2019/nov/01 pass: 5,768; fail: 1 Build 3: aarch64/2019/nov/04 pass: 5,769 Build 4: aarch64/2019/nov/06 pass: 5,766; fail: 2 Build 5: aarch64/2019/nov/08 pass: 5,761 Build 6: aarch64/2019/nov/11 pass: 5,762 Build 7: aarch64/2019/nov/13 pass: 5,764; fail: 1 Build 8: aarch64/2019/nov/15 pass: 5,750 Build 9: aarch64/2019/nov/18 pass: 5,750; fail: 1 Build 10: aarch64/2019/nov/20 pass: 5,752 Build 11: aarch64/2019/nov/22 pass: 5,752; fail: 1 Build 12: aarch64/2019/nov/25 pass: 5,752; fail: 1 Build 13: aarch64/2019/nov/27 pass: 5,752; fail: 2 Build 14: aarch64/2019/nov/29 pass: 5,752; fail: 2 2 fatal errors were detected; please follow the link above for more detail. ------------------------------------------------------------------------------- release/jdk ------------------------------------------------------------------------------- Build 0: aarch64/2019/oct/28 pass: 8,711; fail: 509; error: 18 Build 1: aarch64/2019/oct/30 pass: 8,723; fail: 504; error: 19 Build 2: aarch64/2019/nov/01 pass: 8,774; fail: 506; error: 18 Build 3: aarch64/2019/nov/04 pass: 8,777; fail: 509; error: 17 Build 4: aarch64/2019/nov/06 pass: 8,775; fail: 507; error: 19 Build 5: aarch64/2019/nov/08 pass: 8,774; fail: 510; error: 17 Build 6: aarch64/2019/nov/11 pass: 8,777; fail: 509; error: 15 Build 7: aarch64/2019/nov/13 pass: 8,773; fail: 509; error: 21 Build 8: aarch64/2019/nov/15 pass: 8,756; fail: 511; error: 19 Build 9: aarch64/2019/nov/18 pass: 8,765; fail: 504; error: 18 Build 10: aarch64/2019/nov/20 pass: 8,768; fail: 504; error: 19 Build 11: aarch64/2019/nov/22 pass: 8,769; fail: 507; error: 18 Build 12: aarch64/2019/nov/25 pass: 8,775; fail: 509; error: 17 Build 13: aarch64/2019/nov/27 pass: 8,779; fail: 506; error: 22 Build 14: aarch64/2019/nov/29 pass: 8,784; fail: 503; error: 20 2 fatal errors were detected; please follow the link above for more detail. ------------------------------------------------------------------------------- release/langtools ------------------------------------------------------------------------------- Build 0: aarch64/2019/oct/28 pass: 3,980 Build 1: aarch64/2019/oct/30 pass: 3,980 Build 2: aarch64/2019/nov/01 pass: 3,980 Build 3: aarch64/2019/nov/04 pass: 3,980 Build 4: aarch64/2019/nov/06 pass: 3,980 Build 5: aarch64/2019/nov/08 pass: 3,980 Build 6: aarch64/2019/nov/11 pass: 3,980 Build 7: aarch64/2019/nov/13 pass: 3,980 Build 8: aarch64/2019/nov/15 pass: 3,981 Build 9: aarch64/2019/nov/18 pass: 3,981 Build 10: aarch64/2019/nov/20 pass: 3,981 Build 11: aarch64/2019/nov/22 pass: 3,981 Build 12: aarch64/2019/nov/25 pass: 3,983 Build 13: aarch64/2019/nov/27 pass: 4,006 Build 14: aarch64/2019/nov/29 pass: 4,006 ------------------------------------------------------------------------------- server-release/hotspot ------------------------------------------------------------------------------- Build 0: aarch64/2018/oct/15 pass: 5,787; fail: 18; not run: 90 ------------------------------------------------------------------------------- server-release/jdk ------------------------------------------------------------------------------- Build 0: aarch64/2018/oct/15 pass: 8,476; fail: 686; error: 27 ------------------------------------------------------------------------------- server-release/langtools ------------------------------------------------------------------------------- Build 0: aarch64/2018/oct/15 pass: 3,970; fail: 5 Previous results can be found here: http://openjdk.linaro.org/jdkX/openjdk-jtreg-nightly-tests/index.html SPECjbb2015 composite regression test completed =============================================== This test measures the relative performance of the server compiler running the SPECjbb2015 composite tests and compares the performance against the baseline performance of the server compiler taken on 2016-11-21. In accordance with [1], the SPECjbb2015 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): 7.86x Relative performance: Server critical-jOPS (nc): 9.34x Details of the test setup and historical results may be found here: http://openjdk.linaro.org/jdkX/SPECjbb2015-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 server compiler on 2014-04-01. Relative performance: Zero: 1.0, Server: 201.64 Server 201.64 / Server 2014-04-01 (71.00): 2.84x Details of the test setup and historical results may be found here: http://openjdk.linaro.org/jdkX/hadoop-terasort-benchmark-results/ This is a summary of the jcstress test results ============================================== The build and test results are cycled every 15 days. 2019-10-23 pass rate: 10489/10489, results: http://openjdk.linaro.org/jdkX/jcstress-nightly-runs/2019/296/results/ 2019-10-29 pass rate: 10489/10489, results: http://openjdk.linaro.org/jdkX/jcstress-nightly-runs/2019/301/results/ 2019-10-31 pass rate: 10489/10489, results: http://openjdk.linaro.org/jdkX/jcstress-nightly-runs/2019/303/results/ 2019-11-02 pass rate: 10489/10489, results: http://openjdk.linaro.org/jdkX/jcstress-nightly-runs/2019/305/results/ 2019-11-05 pass rate: 10489/10489, results: http://openjdk.linaro.org/jdkX/jcstress-nightly-runs/2019/308/results/ 2019-11-07 pass rate: 10490/10490, results: http://openjdk.linaro.org/jdkX/jcstress-nightly-runs/2019/310/results/ 2019-11-12 pass rate: 10490/10490, results: http://openjdk.linaro.org/jdkX/jcstress-nightly-runs/2019/315/results/ 2019-11-14 pass rate: 10490/10490, results: http://openjdk.linaro.org/jdkX/jcstress-nightly-runs/2019/317/results/ 2019-11-16 pass rate: 10490/10490, results: http://openjdk.linaro.org/jdkX/jcstress-nightly-runs/2019/319/results/ 2019-11-19 pass rate: 10490/10490, results: http://openjdk.linaro.org/jdkX/jcstress-nightly-runs/2019/322/results/ 2019-11-21 pass rate: 10490/10490, results: http://openjdk.linaro.org/jdkX/jcstress-nightly-runs/2019/324/results/ 2019-11-23 pass rate: 10490/10490, results: http://openjdk.linaro.org/jdkX/jcstress-nightly-runs/2019/326/results/ 2019-11-26 pass rate: 10490/10490, results: http://openjdk.linaro.org/jdkX/jcstress-nightly-runs/2019/329/results/ 2019-12-03 pass rate: 10490/10490, results: http://openjdk.linaro.org/jdkX/jcstress-nightly-runs/2019/331/results/ 2019-12-04 pass rate: 10490/10490, results: http://openjdk.linaro.org/jdkX/jcstress-nightly-runs/2019/333/results/ For detailed information on the test output please refer to: http://openjdk.linaro.org/jdkX/jcstress-nightly-runs/ From ci_notify at linaro.org Wed Dec 4 19:18:34 2019 From: ci_notify at linaro.org (ci_notify at linaro.org) Date: Wed, 4 Dec 2019 19:18:34 +0000 (UTC) Subject: [aarch64-port-dev ] JTREG, JCStress, SPECjbb2015 and Hadoop/Terasort results for OpenJDK 13 on AArch64 Message-ID: <892593208.3428.1575487115401.JavaMail.javamailuser@localhost> This is a summary of the JTREG test results =========================================== The build and test results are cycled every 15 days. For detailed information on the test output please refer to: http://openjdk.linaro.org/jdk13/openjdk-jtreg-nightly-tests/summary/2019/337/summary.html ------------------------------------------------------------------------------- release/hotspot ------------------------------------------------------------------------------- Build 0: aarch64/2019/jul/16 pass: 5,646; fail: 1 Build 1: aarch64/2019/jul/18 pass: 5,644; fail: 2; error: 1 Build 2: aarch64/2019/jul/20 pass: 5,645; fail: 1; error: 1 Build 3: aarch64/2019/jul/23 pass: 5,644; fail: 3 Build 4: aarch64/2019/jul/25 pass: 5,644; fail: 3 Build 5: aarch64/2019/jul/30 pass: 5,645; fail: 2 Build 6: aarch64/2019/aug/01 pass: 5,646; fail: 1 Build 7: aarch64/2019/aug/03 pass: 5,646; fail: 1 Build 8: aarch64/2019/aug/06 pass: 5,645; fail: 2 Build 9: aarch64/2019/aug/08 pass: 5,646; fail: 1 Build 10: aarch64/2019/aug/10 pass: 5,646; fail: 1 Build 11: aarch64/2019/nov/12 pass: 5,652 Build 12: aarch64/2019/nov/14 pass: 5,650; fail: 2 Build 13: aarch64/2019/nov/16 pass: 5,652 Build 14: aarch64/2019/dec/03 pass: 5,651; fail: 1 ------------------------------------------------------------------------------- release/jdk ------------------------------------------------------------------------------- Build 0: aarch64/2019/jul/16 pass: 8,593; fail: 531; error: 30 Build 1: aarch64/2019/jul/18 pass: 8,618; fail: 527; error: 26 Build 2: aarch64/2019/jul/20 pass: 8,619; fail: 519; error: 33 Build 3: aarch64/2019/jul/23 pass: 8,616; fail: 525; error: 30 Build 4: aarch64/2019/jul/25 pass: 8,620; fail: 528; error: 23 Build 5: aarch64/2019/jul/30 pass: 8,610; fail: 529; error: 32 Build 6: aarch64/2019/aug/01 pass: 8,620; fail: 527; error: 24 Build 7: aarch64/2019/aug/03 pass: 8,596; fail: 552; error: 23 Build 8: aarch64/2019/aug/06 pass: 8,616; fail: 528; error: 27 Build 9: aarch64/2019/aug/08 pass: 8,649; fail: 504; error: 18 Build 10: aarch64/2019/aug/10 pass: 8,647; fail: 507; error: 17 Build 11: aarch64/2019/nov/12 pass: 8,650; fail: 513; error: 16 Build 12: aarch64/2019/nov/14 pass: 8,651; fail: 511; error: 17 Build 13: aarch64/2019/nov/16 pass: 8,663; fail: 500; error: 17 Build 14: aarch64/2019/dec/03 pass: 8,671; fail: 493; error: 18 3 fatal errors were detected; please follow the link above for more detail. ------------------------------------------------------------------------------- release/langtools ------------------------------------------------------------------------------- Build 0: aarch64/2019/jul/16 pass: 3,963 Build 1: aarch64/2019/jul/18 pass: 3,964 Build 2: aarch64/2019/jul/20 pass: 3,964 Build 3: aarch64/2019/jul/23 pass: 3,964 Build 4: aarch64/2019/jul/25 pass: 3,964 Build 5: aarch64/2019/jul/30 pass: 3,964 Build 6: aarch64/2019/aug/01 pass: 3,964 Build 7: aarch64/2019/aug/03 pass: 3,964 Build 8: aarch64/2019/aug/06 pass: 3,964 Build 9: aarch64/2019/aug/08 pass: 3,964 Build 10: aarch64/2019/aug/10 pass: 3,964 Build 11: aarch64/2019/nov/12 pass: 3,964 Build 12: aarch64/2019/nov/14 pass: 3,964 Build 13: aarch64/2019/nov/16 pass: 3,964 Build 14: aarch64/2019/dec/03 pass: 3,964 Previous results can be found here: http://openjdk.linaro.org/jdk13/openjdk-jtreg-nightly-tests/index.html SPECjbb2015 composite regression test completed =============================================== This test measures the relative performance of the server compiler running the SPECjbb2015 composite tests and compares the performance against the baseline performance of the server compiler taken on 2016-11-21. In accordance with [1], the SPECjbb2015 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): 7.54x Relative performance: Server critical-jOPS (nc): 9.84x Details of the test setup and historical results may be found here: http://openjdk.linaro.org/jdk13/SPECjbb2015-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 server compiler on 2014-04-01. Relative performance: Zero: 1.0, Server: 204.57 Server 204.57 / Server 2014-04-01 (71.00): 2.88x Details of the test setup and historical results may be found here: http://openjdk.linaro.org/jdk13/hadoop-terasort-benchmark-results/ This is a summary of the jcstress test results ============================================== The build and test results are cycled every 15 days. 2019-07-16 pass rate: 10488/10488, results: http://openjdk.linaro.org/jdk13/jcstress-nightly-runs/2019/197/results/ 2019-07-19 pass rate: 10488/10488, results: http://openjdk.linaro.org/jdk13/jcstress-nightly-runs/2019/199/results/ 2019-07-21 pass rate: 10487/10488, results: http://openjdk.linaro.org/jdk13/jcstress-nightly-runs/2019/201/results/ 2019-07-24 pass rate: 10488/10488, results: http://openjdk.linaro.org/jdk13/jcstress-nightly-runs/2019/204/results/ 2019-07-26 pass rate: 10487/10488, results: http://openjdk.linaro.org/jdk13/jcstress-nightly-runs/2019/206/results/ 2019-07-31 pass rate: 10488/10488, results: http://openjdk.linaro.org/jdk13/jcstress-nightly-runs/2019/211/results/ 2019-08-02 pass rate: 10488/10488, results: http://openjdk.linaro.org/jdk13/jcstress-nightly-runs/2019/213/results/ 2019-08-04 pass rate: 10488/10488, results: http://openjdk.linaro.org/jdk13/jcstress-nightly-runs/2019/215/results/ 2019-08-07 pass rate: 10488/10488, results: http://openjdk.linaro.org/jdk13/jcstress-nightly-runs/2019/218/results/ 2019-08-09 pass rate: 10487/10488, results: http://openjdk.linaro.org/jdk13/jcstress-nightly-runs/2019/220/results/ 2019-08-11 pass rate: 10487/10488, results: http://openjdk.linaro.org/jdk13/jcstress-nightly-runs/2019/222/results/ 2019-11-12 pass rate: 10490/10490, results: http://openjdk.linaro.org/jdk13/jcstress-nightly-runs/2019/316/results/ 2019-11-15 pass rate: 10490/10490, results: http://openjdk.linaro.org/jdk13/jcstress-nightly-runs/2019/318/results/ 2019-11-17 pass rate: 10490/10490, results: http://openjdk.linaro.org/jdk13/jcstress-nightly-runs/2019/320/results/ 2019-12-04 pass rate: 10490/10490, results: http://openjdk.linaro.org/jdk13/jcstress-nightly-runs/2019/337/results/ For detailed information on the test output please refer to: http://openjdk.linaro.org/jdk13/jcstress-nightly-runs/ From ci_notify at linaro.org Thu Dec 5 15:05:15 2019 From: ci_notify at linaro.org (ci_notify at linaro.org) Date: Thu, 5 Dec 2019 15:05:15 +0000 (UTC) Subject: [aarch64-port-dev ] JTREG, JCStress, SPECjbb2015 and Hadoop/Terasort results for OpenJDK JDK on AArch64 Message-ID: <1513218951.3537.1575558316085.JavaMail.javamailuser@localhost> This is a summary of the JTREG test results =========================================== The build and test results are cycled every 15 days. For detailed information on the test output please refer to: http://openjdk.linaro.org/jdkX/openjdk-jtreg-nightly-tests/summary/2019/336/summary.html ------------------------------------------------------------------------------- client-release/hotspot ------------------------------------------------------------------------------- Build 0: aarch64/2018/oct/15 pass: 5,780; fail: 19; not run: 90 ------------------------------------------------------------------------------- client-release/jdk ------------------------------------------------------------------------------- Build 0: aarch64/2018/oct/15 pass: 8,495; fail: 670; error: 23 ------------------------------------------------------------------------------- client-release/langtools ------------------------------------------------------------------------------- Build 0: aarch64/2018/oct/15 pass: 3,970; fail: 5 ------------------------------------------------------------------------------- release/hotspot ------------------------------------------------------------------------------- Build 0: aarch64/2019/oct/30 pass: 5,768 Build 1: aarch64/2019/nov/01 pass: 5,768; fail: 1 Build 2: aarch64/2019/nov/04 pass: 5,769 Build 3: aarch64/2019/nov/06 pass: 5,766; fail: 2 Build 4: aarch64/2019/nov/08 pass: 5,761 Build 5: aarch64/2019/nov/11 pass: 5,762 Build 6: aarch64/2019/nov/13 pass: 5,764; fail: 1 Build 7: aarch64/2019/nov/15 pass: 5,750 Build 8: aarch64/2019/nov/18 pass: 5,750; fail: 1 Build 9: aarch64/2019/nov/20 pass: 5,752 Build 10: aarch64/2019/nov/22 pass: 5,752; fail: 1 Build 11: aarch64/2019/nov/25 pass: 5,752; fail: 1 Build 12: aarch64/2019/nov/27 pass: 5,752; fail: 2 Build 13: aarch64/2019/nov/29 pass: 5,752; fail: 2 Build 14: aarch64/2019/dec/02 pass: 5,753; fail: 4 1 fatal errors were detected; please follow the link above for more detail. ------------------------------------------------------------------------------- release/jdk ------------------------------------------------------------------------------- Build 0: aarch64/2019/oct/30 pass: 8,723; fail: 504; error: 19 Build 1: aarch64/2019/nov/01 pass: 8,774; fail: 506; error: 18 Build 2: aarch64/2019/nov/04 pass: 8,777; fail: 509; error: 17 Build 3: aarch64/2019/nov/06 pass: 8,775; fail: 507; error: 19 Build 4: aarch64/2019/nov/08 pass: 8,774; fail: 510; error: 17 Build 5: aarch64/2019/nov/11 pass: 8,777; fail: 509; error: 15 Build 6: aarch64/2019/nov/13 pass: 8,773; fail: 509; error: 21 Build 7: aarch64/2019/nov/15 pass: 8,756; fail: 511; error: 19 Build 8: aarch64/2019/nov/18 pass: 8,765; fail: 504; error: 18 Build 9: aarch64/2019/nov/20 pass: 8,768; fail: 504; error: 19 Build 10: aarch64/2019/nov/22 pass: 8,769; fail: 507; error: 18 Build 11: aarch64/2019/nov/25 pass: 8,775; fail: 509; error: 17 Build 12: aarch64/2019/nov/27 pass: 8,779; fail: 506; error: 22 Build 13: aarch64/2019/nov/29 pass: 8,784; fail: 503; error: 20 Build 14: aarch64/2019/dec/02 pass: 8,784; fail: 507; error: 19 5 fatal errors were detected; please follow the link above for more detail. ------------------------------------------------------------------------------- release/langtools ------------------------------------------------------------------------------- Build 0: aarch64/2019/oct/30 pass: 3,980 Build 1: aarch64/2019/nov/01 pass: 3,980 Build 2: aarch64/2019/nov/04 pass: 3,980 Build 3: aarch64/2019/nov/06 pass: 3,980 Build 4: aarch64/2019/nov/08 pass: 3,980 Build 5: aarch64/2019/nov/11 pass: 3,980 Build 6: aarch64/2019/nov/13 pass: 3,980 Build 7: aarch64/2019/nov/15 pass: 3,981 Build 8: aarch64/2019/nov/18 pass: 3,981 Build 9: aarch64/2019/nov/20 pass: 3,981 Build 10: aarch64/2019/nov/22 pass: 3,981 Build 11: aarch64/2019/nov/25 pass: 3,983 Build 12: aarch64/2019/nov/27 pass: 4,006 Build 13: aarch64/2019/nov/29 pass: 4,006 Build 14: aarch64/2019/dec/02 pass: 4,002; fail: 5; error: 1 ------------------------------------------------------------------------------- server-release/hotspot ------------------------------------------------------------------------------- Build 0: aarch64/2018/oct/15 pass: 5,787; fail: 18; not run: 90 ------------------------------------------------------------------------------- server-release/jdk ------------------------------------------------------------------------------- Build 0: aarch64/2018/oct/15 pass: 8,476; fail: 686; error: 27 ------------------------------------------------------------------------------- server-release/langtools ------------------------------------------------------------------------------- Build 0: aarch64/2018/oct/15 pass: 3,970; fail: 5 Previous results can be found here: http://openjdk.linaro.org/jdkX/openjdk-jtreg-nightly-tests/index.html SPECjbb2015 composite regression test completed =============================================== This test measures the relative performance of the server compiler running the SPECjbb2015 composite tests and compares the performance against the baseline performance of the server compiler taken on 2016-11-21. In accordance with [1], the SPECjbb2015 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): 7.96x Relative performance: Server critical-jOPS (nc): 10.33x Details of the test setup and historical results may be found here: http://openjdk.linaro.org/jdkX/SPECjbb2015-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 server compiler on 2014-04-01. Relative performance: Zero: 1.0, Server: 210.67 Server 210.67 / Server 2014-04-01 (71.00): 2.97x Details of the test setup and historical results may be found here: http://openjdk.linaro.org/jdkX/hadoop-terasort-benchmark-results/ This is a summary of the jcstress test results ============================================== The build and test results are cycled every 15 days. 2019-10-29 pass rate: 10489/10489, results: http://openjdk.linaro.org/jdkX/jcstress-nightly-runs/2019/301/results/ 2019-10-31 pass rate: 10489/10489, results: http://openjdk.linaro.org/jdkX/jcstress-nightly-runs/2019/303/results/ 2019-11-02 pass rate: 10489/10489, results: http://openjdk.linaro.org/jdkX/jcstress-nightly-runs/2019/305/results/ 2019-11-05 pass rate: 10489/10489, results: http://openjdk.linaro.org/jdkX/jcstress-nightly-runs/2019/308/results/ 2019-11-07 pass rate: 10490/10490, results: http://openjdk.linaro.org/jdkX/jcstress-nightly-runs/2019/310/results/ 2019-11-12 pass rate: 10490/10490, results: http://openjdk.linaro.org/jdkX/jcstress-nightly-runs/2019/315/results/ 2019-11-14 pass rate: 10490/10490, results: http://openjdk.linaro.org/jdkX/jcstress-nightly-runs/2019/317/results/ 2019-11-16 pass rate: 10490/10490, results: http://openjdk.linaro.org/jdkX/jcstress-nightly-runs/2019/319/results/ 2019-11-19 pass rate: 10490/10490, results: http://openjdk.linaro.org/jdkX/jcstress-nightly-runs/2019/322/results/ 2019-11-21 pass rate: 10490/10490, results: http://openjdk.linaro.org/jdkX/jcstress-nightly-runs/2019/324/results/ 2019-11-23 pass rate: 10490/10490, results: http://openjdk.linaro.org/jdkX/jcstress-nightly-runs/2019/326/results/ 2019-11-26 pass rate: 10490/10490, results: http://openjdk.linaro.org/jdkX/jcstress-nightly-runs/2019/329/results/ 2019-12-03 pass rate: 10490/10490, results: http://openjdk.linaro.org/jdkX/jcstress-nightly-runs/2019/331/results/ 2019-12-04 pass rate: 10490/10490, results: http://openjdk.linaro.org/jdkX/jcstress-nightly-runs/2019/333/results/ 2019-12-05 pass rate: 10490/10490, results: http://openjdk.linaro.org/jdkX/jcstress-nightly-runs/2019/336/results/ For detailed information on the test output please refer to: http://openjdk.linaro.org/jdkX/jcstress-nightly-runs/ From adinn at redhat.com Thu Dec 5 19:47:41 2019 From: adinn at redhat.com (Andrew Dinn) Date: Thu, 5 Dec 2019 19:47:41 +0000 Subject: [aarch64-port-dev ] 8233948: AArch64: Incorrect mapping between OptoReg and VMReg for high 64 bits of Vector Register In-Reply-To: References: Message-ID: <96a686bd-0668-1be8-1ca0-54c3f2dd9566@redhat.com> Hi Joshua, On 03/12/2019 12:26, Joshua Zhu (Arm Technology China) wrote: >> Yes, of course. I updated webrev according to your review comments. >> http://cr.openjdk.java.net/~jzhu/8233948/webrev.01/ > >>> Also, could you report what testing you did before and after your >>> change (other than checking the dump output). You will probably need >>> to repeat it to ensure these extra changes are ok. >> >> Oh, Sorry for that. I did not mention my testing in my previous mail (My >> initial RFR mail is too long). >> I ran full jtreg tests without new failure introduced. >> I will re-run it against the new webrev and will let you know the results. >> Thanks again for your review. > > Testing: Passed hotspot_all_no_apps, jdk_core and langtools:tier1 without new failure introduced. > Please let me know if any comments. Thanks! That looks good thanks. Also, thank you for correcting my arithmetic when computing vect_words. Approved for pushing. regards, Andrew Dinn ----------- From Joshua.Zhu at arm.com Fri Dec 6 02:34:54 2019 From: Joshua.Zhu at arm.com (Joshua Zhu (Arm Technology China)) Date: Fri, 6 Dec 2019 02:34:54 +0000 Subject: [aarch64-port-dev ] 8233948: AArch64: Incorrect mapping between OptoReg and VMReg for high 64 bits of Vector Register In-Reply-To: <96a686bd-0668-1be8-1ca0-54c3f2dd9566@redhat.com> References: <96a686bd-0668-1be8-1ca0-54c3f2dd9566@redhat.com> Message-ID: Hi, > > Testing: Passed hotspot_all_no_apps, jdk_core and langtools:tier1 without > new failure introduced. > > Please let me know if any comments. Thanks! > > That looks good thanks. > > Also, thank you for correcting my arithmetic when computing vect_words. > > Approved for pushing. Andrew Dinn, thanks a lot for your review and comments! Ningsheng, could you please help push this patch? Thanks! Best Regards, Joshua From ningsheng.jian at arm.com Fri Dec 6 02:44:33 2019 From: ningsheng.jian at arm.com (Ningsheng Jian) Date: Fri, 6 Dec 2019 10:44:33 +0800 Subject: [aarch64-port-dev ] 8233948: AArch64: Incorrect mapping between OptoReg and VMReg for high 64 bits of Vector Register In-Reply-To: References: <96a686bd-0668-1be8-1ca0-54c3f2dd9566@redhat.com> Message-ID: <0250139e-3795-dfb0-d33c-4ea3d8370484@arm.com> Pushed. Thanks, Ningsheng On 12/6/19 10:34 AM, Joshua Zhu (Arm Technology China) wrote: > Hi, > >>> Testing: Passed hotspot_all_no_apps, jdk_core and langtools:tier1 without >> new failure introduced. >>> Please let me know if any comments. Thanks! >> >> That looks good thanks. >> >> Also, thank you for correcting my arithmetic when computing vect_words. >> >> Approved for pushing. > > Andrew Dinn, thanks a lot for your review and comments! > Ningsheng, could you please help push this patch? Thanks! > > Best Regards, > Joshua > From ci_notify at linaro.org Sat Dec 7 04:54:10 2019 From: ci_notify at linaro.org (ci_notify at linaro.org) Date: Sat, 7 Dec 2019 04:54:10 +0000 (UTC) Subject: [aarch64-port-dev ] JTREG, JCStress, SPECjbb2015 and Hadoop/Terasort results for OpenJDK JDK on AArch64 Message-ID: <307340253.3761.1575694451779.JavaMail.javamailuser@localhost> This is a summary of the JTREG test results =========================================== The build and test results are cycled every 15 days. For detailed information on the test output please refer to: http://openjdk.linaro.org/jdkX/openjdk-jtreg-nightly-tests/summary/2019/338/summary.html ------------------------------------------------------------------------------- client-release/hotspot ------------------------------------------------------------------------------- Build 0: aarch64/2018/oct/15 pass: 5,780; fail: 19; not run: 90 ------------------------------------------------------------------------------- client-release/jdk ------------------------------------------------------------------------------- Build 0: aarch64/2018/oct/15 pass: 8,495; fail: 670; error: 23 ------------------------------------------------------------------------------- client-release/langtools ------------------------------------------------------------------------------- Build 0: aarch64/2018/oct/15 pass: 3,970; fail: 5 ------------------------------------------------------------------------------- release/hotspot ------------------------------------------------------------------------------- Build 0: aarch64/2019/nov/01 pass: 5,768; fail: 1 Build 1: aarch64/2019/nov/04 pass: 5,769 Build 2: aarch64/2019/nov/06 pass: 5,766; fail: 2 Build 3: aarch64/2019/nov/08 pass: 5,761 Build 4: aarch64/2019/nov/11 pass: 5,762 Build 5: aarch64/2019/nov/13 pass: 5,764; fail: 1 Build 6: aarch64/2019/nov/15 pass: 5,750 Build 7: aarch64/2019/nov/18 pass: 5,750; fail: 1 Build 8: aarch64/2019/nov/20 pass: 5,752 Build 9: aarch64/2019/nov/22 pass: 5,752; fail: 1 Build 10: aarch64/2019/nov/25 pass: 5,752; fail: 1 Build 11: aarch64/2019/nov/27 pass: 5,752; fail: 2 Build 12: aarch64/2019/nov/29 pass: 5,752; fail: 2 Build 13: aarch64/2019/dec/02 pass: 5,753; fail: 4 Build 14: aarch64/2019/dec/04 pass: 5,755; fail: 2 1 fatal errors were detected; please follow the link above for more detail. ------------------------------------------------------------------------------- release/jdk ------------------------------------------------------------------------------- Build 0: aarch64/2019/nov/01 pass: 8,774; fail: 506; error: 18 Build 1: aarch64/2019/nov/04 pass: 8,777; fail: 509; error: 17 Build 2: aarch64/2019/nov/06 pass: 8,775; fail: 507; error: 19 Build 3: aarch64/2019/nov/08 pass: 8,774; fail: 510; error: 17 Build 4: aarch64/2019/nov/11 pass: 8,777; fail: 509; error: 15 Build 5: aarch64/2019/nov/13 pass: 8,773; fail: 509; error: 21 Build 6: aarch64/2019/nov/15 pass: 8,756; fail: 511; error: 19 Build 7: aarch64/2019/nov/18 pass: 8,765; fail: 504; error: 18 Build 8: aarch64/2019/nov/20 pass: 8,768; fail: 504; error: 19 Build 9: aarch64/2019/nov/22 pass: 8,769; fail: 507; error: 18 Build 10: aarch64/2019/nov/25 pass: 8,775; fail: 509; error: 17 Build 11: aarch64/2019/nov/27 pass: 8,779; fail: 506; error: 22 Build 12: aarch64/2019/nov/29 pass: 8,784; fail: 503; error: 20 Build 13: aarch64/2019/dec/02 pass: 8,784; fail: 507; error: 19 Build 14: aarch64/2019/dec/04 pass: 8,788; fail: 505; error: 17 5 fatal errors were detected; please follow the link above for more detail. ------------------------------------------------------------------------------- release/langtools ------------------------------------------------------------------------------- Build 0: aarch64/2019/nov/01 pass: 3,980 Build 1: aarch64/2019/nov/04 pass: 3,980 Build 2: aarch64/2019/nov/06 pass: 3,980 Build 3: aarch64/2019/nov/08 pass: 3,980 Build 4: aarch64/2019/nov/11 pass: 3,980 Build 5: aarch64/2019/nov/13 pass: 3,980 Build 6: aarch64/2019/nov/15 pass: 3,981 Build 7: aarch64/2019/nov/18 pass: 3,981 Build 8: aarch64/2019/nov/20 pass: 3,981 Build 9: aarch64/2019/nov/22 pass: 3,981 Build 10: aarch64/2019/nov/25 pass: 3,983 Build 11: aarch64/2019/nov/27 pass: 4,006 Build 12: aarch64/2019/nov/29 pass: 4,006 Build 13: aarch64/2019/dec/02 pass: 4,002; fail: 5; error: 1 Build 14: aarch64/2019/dec/04 pass: 4,008 ------------------------------------------------------------------------------- server-release/hotspot ------------------------------------------------------------------------------- Build 0: aarch64/2018/oct/15 pass: 5,787; fail: 18; not run: 90 ------------------------------------------------------------------------------- server-release/jdk ------------------------------------------------------------------------------- Build 0: aarch64/2018/oct/15 pass: 8,476; fail: 686; error: 27 ------------------------------------------------------------------------------- server-release/langtools ------------------------------------------------------------------------------- Build 0: aarch64/2018/oct/15 pass: 3,970; fail: 5 Previous results can be found here: http://openjdk.linaro.org/jdkX/openjdk-jtreg-nightly-tests/index.html SPECjbb2015 composite regression test completed =============================================== This test measures the relative performance of the server compiler running the SPECjbb2015 composite tests and compares the performance against the baseline performance of the server compiler taken on 2016-11-21. In accordance with [1], the SPECjbb2015 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): 7.75x Relative performance: Server critical-jOPS (nc): 9.29x Details of the test setup and historical results may be found here: http://openjdk.linaro.org/jdkX/SPECjbb2015-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 server compiler on 2014-04-01. Relative performance: Zero: 1.0, Server: 207.57 Server 207.57 / Server 2014-04-01 (71.00): 2.92x Details of the test setup and historical results may be found here: http://openjdk.linaro.org/jdkX/hadoop-terasort-benchmark-results/ This is a summary of the jcstress test results ============================================== The build and test results are cycled every 15 days. 2019-10-31 pass rate: 10489/10489, results: http://openjdk.linaro.org/jdkX/jcstress-nightly-runs/2019/303/results/ 2019-11-02 pass rate: 10489/10489, results: http://openjdk.linaro.org/jdkX/jcstress-nightly-runs/2019/305/results/ 2019-11-05 pass rate: 10489/10489, results: http://openjdk.linaro.org/jdkX/jcstress-nightly-runs/2019/308/results/ 2019-11-07 pass rate: 10490/10490, results: http://openjdk.linaro.org/jdkX/jcstress-nightly-runs/2019/310/results/ 2019-11-12 pass rate: 10490/10490, results: http://openjdk.linaro.org/jdkX/jcstress-nightly-runs/2019/315/results/ 2019-11-14 pass rate: 10490/10490, results: http://openjdk.linaro.org/jdkX/jcstress-nightly-runs/2019/317/results/ 2019-11-16 pass rate: 10490/10490, results: http://openjdk.linaro.org/jdkX/jcstress-nightly-runs/2019/319/results/ 2019-11-19 pass rate: 10490/10490, results: http://openjdk.linaro.org/jdkX/jcstress-nightly-runs/2019/322/results/ 2019-11-21 pass rate: 10490/10490, results: http://openjdk.linaro.org/jdkX/jcstress-nightly-runs/2019/324/results/ 2019-11-23 pass rate: 10490/10490, results: http://openjdk.linaro.org/jdkX/jcstress-nightly-runs/2019/326/results/ 2019-11-26 pass rate: 10490/10490, results: http://openjdk.linaro.org/jdkX/jcstress-nightly-runs/2019/329/results/ 2019-12-03 pass rate: 10490/10490, results: http://openjdk.linaro.org/jdkX/jcstress-nightly-runs/2019/331/results/ 2019-12-04 pass rate: 10490/10490, results: http://openjdk.linaro.org/jdkX/jcstress-nightly-runs/2019/333/results/ 2019-12-05 pass rate: 10490/10490, results: http://openjdk.linaro.org/jdkX/jcstress-nightly-runs/2019/336/results/ 2019-12-07 pass rate: 10490/10490, results: http://openjdk.linaro.org/jdkX/jcstress-nightly-runs/2019/338/results/ For detailed information on the test output please refer to: http://openjdk.linaro.org/jdkX/jcstress-nightly-runs/ From ci_notify at linaro.org Sat Dec 7 04:57:12 2019 From: ci_notify at linaro.org (ci_notify at linaro.org) Date: Sat, 7 Dec 2019 04:57:12 +0000 (UTC) Subject: [aarch64-port-dev ] JTREG, JCStress, SPECjbb2015 and Hadoop/Terasort results for OpenJDK 11u on AArch64 Message-ID: <1306225034.3763.1575694632896.JavaMail.javamailuser@localhost> This is a summary of the JTREG test results =========================================== The build and test results are cycled every 15 days. For detailed information on the test output please refer to: http://openjdk.linaro.org/jdk11u/openjdk-jtreg-nightly-tests/summary/2019/339/summary.html ------------------------------------------------------------------------------- release/hotspot ------------------------------------------------------------------------------- Build 0: aarch64/2019/aug/10 pass: 5,747; fail: 4 Build 1: aarch64/2019/aug/15 pass: 5,753; fail: 4 Build 2: aarch64/2019/aug/22 pass: 5,755; fail: 4 Build 3: aarch64/2019/sep/04 pass: 5,764; fail: 2 Build 4: aarch64/2019/sep/05 pass: 5,764; fail: 2 Build 5: aarch64/2019/sep/10 pass: 5,764; fail: 2 Build 6: aarch64/2019/sep/17 pass: 5,763; fail: 3 Build 7: aarch64/2019/sep/21 pass: 5,764; fail: 2 Build 8: aarch64/2019/oct/04 pass: 5,764; fail: 2 Build 9: aarch64/2019/oct/17 pass: 5,764; fail: 2 Build 10: aarch64/2019/oct/31 pass: 5,784; fail: 1 Build 11: aarch64/2019/nov/09 pass: 5,773; fail: 3 Build 12: aarch64/2019/nov/16 pass: 5,775; fail: 1 Build 13: aarch64/2019/nov/21 pass: 5,775; fail: 1 Build 14: aarch64/2019/dec/05 pass: 5,775; fail: 1 ------------------------------------------------------------------------------- release/jdk ------------------------------------------------------------------------------- Build 0: aarch64/2019/aug/10 pass: 8,450; fail: 485; error: 16 Build 1: aarch64/2019/aug/15 pass: 8,443; fail: 496; error: 13 Build 2: aarch64/2019/aug/22 pass: 8,446; fail: 494; error: 15 Build 3: aarch64/2019/sep/04 pass: 8,483; fail: 465; error: 10 Build 4: aarch64/2019/sep/05 pass: 8,465; fail: 479; error: 14 Build 5: aarch64/2019/sep/10 pass: 8,444; fail: 500; error: 14 Build 6: aarch64/2019/sep/17 pass: 8,462; fail: 482; error: 12 Build 7: aarch64/2019/sep/21 pass: 8,467; fail: 478; error: 13 Build 8: aarch64/2019/oct/04 pass: 8,444; fail: 498; error: 16 Build 9: aarch64/2019/oct/17 pass: 8,452; fail: 493; error: 16 Build 10: aarch64/2019/oct/31 pass: 8,468; fail: 490; error: 14 Build 11: aarch64/2019/nov/09 pass: 8,487; fail: 470; error: 16 Build 12: aarch64/2019/nov/16 pass: 8,475; fail: 484; error: 15 Build 13: aarch64/2019/nov/21 pass: 8,489; fail: 497; error: 13 Build 14: aarch64/2019/dec/05 pass: 8,492; fail: 501; error: 11 2 fatal errors were detected; please follow the link above for more detail. ------------------------------------------------------------------------------- release/langtools ------------------------------------------------------------------------------- Build 0: aarch64/2019/aug/10 pass: 3,909 Build 1: aarch64/2019/aug/15 pass: 3,909 Build 2: aarch64/2019/aug/22 pass: 3,909 Build 3: aarch64/2019/sep/04 pass: 3,910 Build 4: aarch64/2019/sep/05 pass: 3,910 Build 5: aarch64/2019/sep/10 pass: 3,910 Build 6: aarch64/2019/sep/17 pass: 3,910 Build 7: aarch64/2019/sep/21 pass: 3,910 Build 8: aarch64/2019/oct/04 pass: 3,910 Build 9: aarch64/2019/oct/17 pass: 3,910 Build 10: aarch64/2019/oct/31 pass: 3,910 Build 11: aarch64/2019/nov/09 pass: 3,910 Build 12: aarch64/2019/nov/16 pass: 3,910 Build 13: aarch64/2019/nov/21 pass: 3,910 Build 14: aarch64/2019/dec/05 pass: 3,910 Previous results can be found here: http://openjdk.linaro.org/jdk11u/openjdk-jtreg-nightly-tests/index.html SPECjbb2015 composite regression test completed =============================================== This test measures the relative performance of the server compiler running the SPECjbb2015 composite tests and compares the performance against the baseline performance of the server compiler taken on 2016-11-21. In accordance with [1], the SPECjbb2015 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): 7.38x Relative performance: Server critical-jOPS (nc): 7.60x Details of the test setup and historical results may be found here: http://openjdk.linaro.org/jdk11u/SPECjbb2015-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 server compiler on 2014-04-01. Relative performance: Zero: 1.0, Server: 207.57 Server 207.57 / Server 2014-04-01 (71.00): 2.92x Details of the test setup and historical results may be found here: http://openjdk.linaro.org/jdk11u/hadoop-terasort-benchmark-results/ This is a summary of the jcstress test results ============================================== The build and test results are cycled every 15 days. 2019-08-11 pass rate: 10488/10488, results: http://openjdk.linaro.org/jdk11u/jcstress-nightly-runs/2019/222/results/ 2019-08-16 pass rate: 10489/10489, results: http://openjdk.linaro.org/jdk11u/jcstress-nightly-runs/2019/227/results/ 2019-08-23 pass rate: 10489/10489, results: http://openjdk.linaro.org/jdk11u/jcstress-nightly-runs/2019/234/results/ 2019-09-05 pass rate: 10489/10489, results: http://openjdk.linaro.org/jdk11u/jcstress-nightly-runs/2019/247/results/ 2019-09-07 pass rate: 10489/10489, results: http://openjdk.linaro.org/jdk11u/jcstress-nightly-runs/2019/248/results/ 2019-09-11 pass rate: 10489/10489, results: http://openjdk.linaro.org/jdk11u/jcstress-nightly-runs/2019/253/results/ 2019-09-18 pass rate: 10489/10489, results: http://openjdk.linaro.org/jdk11u/jcstress-nightly-runs/2019/260/results/ 2019-09-22 pass rate: 10489/10489, results: http://openjdk.linaro.org/jdk11u/jcstress-nightly-runs/2019/264/results/ 2019-10-05 pass rate: 10489/10489, results: http://openjdk.linaro.org/jdk11u/jcstress-nightly-runs/2019/277/results/ 2019-10-18 pass rate: 10489/10489, results: http://openjdk.linaro.org/jdk11u/jcstress-nightly-runs/2019/290/results/ 2019-11-01 pass rate: 10489/10489, results: http://openjdk.linaro.org/jdk11u/jcstress-nightly-runs/2019/304/results/ 2019-11-10 pass rate: 10490/10490, results: http://openjdk.linaro.org/jdk11u/jcstress-nightly-runs/2019/313/results/ 2019-11-17 pass rate: 10490/10490, results: http://openjdk.linaro.org/jdk11u/jcstress-nightly-runs/2019/320/results/ 2019-11-22 pass rate: 10490/10490, results: http://openjdk.linaro.org/jdk11u/jcstress-nightly-runs/2019/325/results/ 2019-12-07 pass rate: 10490/10490, results: http://openjdk.linaro.org/jdk11u/jcstress-nightly-runs/2019/339/results/ For detailed information on the test output please refer to: http://openjdk.linaro.org/jdk11u/jcstress-nightly-runs/ From ci_notify at linaro.org Sun Dec 8 08:52:00 2019 From: ci_notify at linaro.org (ci_notify at linaro.org) Date: Sun, 8 Dec 2019 08:52:00 +0000 (UTC) Subject: [aarch64-port-dev ] JTREG, JCStress, SPECjbb2015 and Hadoop/Terasort results for OpenJDK JDK on AArch64 Message-ID: <1613833027.3875.1575795120805.JavaMail.javamailuser@localhost> This is a summary of the JTREG test results =========================================== The build and test results are cycled every 15 days. For detailed information on the test output please refer to: http://openjdk.linaro.org/jdkX/openjdk-jtreg-nightly-tests/summary/2019/341/summary.html ------------------------------------------------------------------------------- client-release/hotspot ------------------------------------------------------------------------------- Build 0: aarch64/2018/oct/15 pass: 5,780; fail: 19; not run: 90 ------------------------------------------------------------------------------- client-release/jdk ------------------------------------------------------------------------------- Build 0: aarch64/2018/oct/15 pass: 8,495; fail: 670; error: 23 ------------------------------------------------------------------------------- client-release/langtools ------------------------------------------------------------------------------- Build 0: aarch64/2018/oct/15 pass: 3,970; fail: 5 ------------------------------------------------------------------------------- release/hotspot ------------------------------------------------------------------------------- Build 0: aarch64/2019/nov/04 pass: 5,769 Build 1: aarch64/2019/nov/06 pass: 5,766; fail: 2 Build 2: aarch64/2019/nov/08 pass: 5,761 Build 3: aarch64/2019/nov/11 pass: 5,762 Build 4: aarch64/2019/nov/13 pass: 5,764; fail: 1 Build 5: aarch64/2019/nov/15 pass: 5,750 Build 6: aarch64/2019/nov/18 pass: 5,750; fail: 1 Build 7: aarch64/2019/nov/20 pass: 5,752 Build 8: aarch64/2019/nov/22 pass: 5,752; fail: 1 Build 9: aarch64/2019/nov/25 pass: 5,752; fail: 1 Build 10: aarch64/2019/nov/27 pass: 5,752; fail: 2 Build 11: aarch64/2019/nov/29 pass: 5,752; fail: 2 Build 12: aarch64/2019/dec/02 pass: 5,753; fail: 4 Build 13: aarch64/2019/dec/04 pass: 5,755; fail: 2 Build 14: aarch64/2019/dec/07 pass: 5,762; fail: 1 ------------------------------------------------------------------------------- release/jdk ------------------------------------------------------------------------------- Build 0: aarch64/2019/nov/04 pass: 8,777; fail: 509; error: 17 Build 1: aarch64/2019/nov/06 pass: 8,775; fail: 507; error: 19 Build 2: aarch64/2019/nov/08 pass: 8,774; fail: 510; error: 17 Build 3: aarch64/2019/nov/11 pass: 8,777; fail: 509; error: 15 Build 4: aarch64/2019/nov/13 pass: 8,773; fail: 509; error: 21 Build 5: aarch64/2019/nov/15 pass: 8,756; fail: 511; error: 19 Build 6: aarch64/2019/nov/18 pass: 8,765; fail: 504; error: 18 Build 7: aarch64/2019/nov/20 pass: 8,768; fail: 504; error: 19 Build 8: aarch64/2019/nov/22 pass: 8,769; fail: 507; error: 18 Build 9: aarch64/2019/nov/25 pass: 8,775; fail: 509; error: 17 Build 10: aarch64/2019/nov/27 pass: 8,779; fail: 506; error: 22 Build 11: aarch64/2019/nov/29 pass: 8,784; fail: 503; error: 20 Build 12: aarch64/2019/dec/02 pass: 8,784; fail: 507; error: 19 Build 13: aarch64/2019/dec/04 pass: 8,788; fail: 505; error: 17 Build 14: aarch64/2019/dec/07 pass: 8,819; fail: 524; error: 17 2 fatal errors were detected; please follow the link above for more detail. ------------------------------------------------------------------------------- release/langtools ------------------------------------------------------------------------------- Build 0: aarch64/2019/nov/04 pass: 3,980 Build 1: aarch64/2019/nov/06 pass: 3,980 Build 2: aarch64/2019/nov/08 pass: 3,980 Build 3: aarch64/2019/nov/11 pass: 3,980 Build 4: aarch64/2019/nov/13 pass: 3,980 Build 5: aarch64/2019/nov/15 pass: 3,981 Build 6: aarch64/2019/nov/18 pass: 3,981 Build 7: aarch64/2019/nov/20 pass: 3,981 Build 8: aarch64/2019/nov/22 pass: 3,981 Build 9: aarch64/2019/nov/25 pass: 3,983 Build 10: aarch64/2019/nov/27 pass: 4,006 Build 11: aarch64/2019/nov/29 pass: 4,006 Build 12: aarch64/2019/dec/02 pass: 4,002; fail: 5; error: 1 Build 13: aarch64/2019/dec/04 pass: 4,008 Build 14: aarch64/2019/dec/07 pass: 4,019 ------------------------------------------------------------------------------- server-release/hotspot ------------------------------------------------------------------------------- Build 0: aarch64/2018/oct/15 pass: 5,787; fail: 18; not run: 90 ------------------------------------------------------------------------------- server-release/jdk ------------------------------------------------------------------------------- Build 0: aarch64/2018/oct/15 pass: 8,476; fail: 686; error: 27 ------------------------------------------------------------------------------- server-release/langtools ------------------------------------------------------------------------------- Build 0: aarch64/2018/oct/15 pass: 3,970; fail: 5 Previous results can be found here: http://openjdk.linaro.org/jdkX/openjdk-jtreg-nightly-tests/index.html SPECjbb2015 composite regression test completed =============================================== This test measures the relative performance of the server compiler running the SPECjbb2015 composite tests and compares the performance against the baseline performance of the server compiler taken on 2016-11-21. In accordance with [1], the SPECjbb2015 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): 7.34x Relative performance: Server critical-jOPS (nc): 9.52x Details of the test setup and historical results may be found here: http://openjdk.linaro.org/jdkX/SPECjbb2015-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 server compiler on 2014-04-01. Relative performance: Zero: 1.0, Server: 204.57 Server 204.57 / Server 2014-04-01 (71.00): 2.88x Details of the test setup and historical results may be found here: http://openjdk.linaro.org/jdkX/hadoop-terasort-benchmark-results/ This is a summary of the jcstress test results ============================================== The build and test results are cycled every 15 days. 2019-11-02 pass rate: 10489/10489, results: http://openjdk.linaro.org/jdkX/jcstress-nightly-runs/2019/305/results/ 2019-11-05 pass rate: 10489/10489, results: http://openjdk.linaro.org/jdkX/jcstress-nightly-runs/2019/308/results/ 2019-11-07 pass rate: 10490/10490, results: http://openjdk.linaro.org/jdkX/jcstress-nightly-runs/2019/310/results/ 2019-11-12 pass rate: 10490/10490, results: http://openjdk.linaro.org/jdkX/jcstress-nightly-runs/2019/315/results/ 2019-11-14 pass rate: 10490/10490, results: http://openjdk.linaro.org/jdkX/jcstress-nightly-runs/2019/317/results/ 2019-11-16 pass rate: 10490/10490, results: http://openjdk.linaro.org/jdkX/jcstress-nightly-runs/2019/319/results/ 2019-11-19 pass rate: 10490/10490, results: http://openjdk.linaro.org/jdkX/jcstress-nightly-runs/2019/322/results/ 2019-11-21 pass rate: 10490/10490, results: http://openjdk.linaro.org/jdkX/jcstress-nightly-runs/2019/324/results/ 2019-11-23 pass rate: 10490/10490, results: http://openjdk.linaro.org/jdkX/jcstress-nightly-runs/2019/326/results/ 2019-11-26 pass rate: 10490/10490, results: http://openjdk.linaro.org/jdkX/jcstress-nightly-runs/2019/329/results/ 2019-12-03 pass rate: 10490/10490, results: http://openjdk.linaro.org/jdkX/jcstress-nightly-runs/2019/331/results/ 2019-12-04 pass rate: 10490/10490, results: http://openjdk.linaro.org/jdkX/jcstress-nightly-runs/2019/333/results/ 2019-12-05 pass rate: 10490/10490, results: http://openjdk.linaro.org/jdkX/jcstress-nightly-runs/2019/336/results/ 2019-12-07 pass rate: 10490/10490, results: http://openjdk.linaro.org/jdkX/jcstress-nightly-runs/2019/338/results/ 2019-12-08 pass rate: 10490/10490, results: http://openjdk.linaro.org/jdkX/jcstress-nightly-runs/2019/341/results/ For detailed information on the test output please refer to: http://openjdk.linaro.org/jdkX/jcstress-nightly-runs/ From ci_notify at linaro.org Mon Dec 9 04:24:31 2019 From: ci_notify at linaro.org (ci_notify at linaro.org) Date: Mon, 9 Dec 2019 04:24:31 +0000 (UTC) Subject: [aarch64-port-dev ] JTREG, JCStress, SPECjbb2015 and Hadoop/Terasort results for OpenJDK 11u on AArch64 Message-ID: <500177784.3919.1575865471989.JavaMail.javamailuser@localhost> This is a summary of the JTREG test results =========================================== The build and test results are cycled every 15 days. For detailed information on the test output please refer to: http://openjdk.linaro.org/jdk11u/openjdk-jtreg-nightly-tests/summary/2019/342/summary.html ------------------------------------------------------------------------------- release/hotspot ------------------------------------------------------------------------------- Build 0: aarch64/2019/aug/15 pass: 5,753; fail: 4 Build 1: aarch64/2019/aug/22 pass: 5,755; fail: 4 Build 2: aarch64/2019/sep/04 pass: 5,764; fail: 2 Build 3: aarch64/2019/sep/05 pass: 5,764; fail: 2 Build 4: aarch64/2019/sep/10 pass: 5,764; fail: 2 Build 5: aarch64/2019/sep/17 pass: 5,763; fail: 3 Build 6: aarch64/2019/sep/21 pass: 5,764; fail: 2 Build 7: aarch64/2019/oct/04 pass: 5,764; fail: 2 Build 8: aarch64/2019/oct/17 pass: 5,764; fail: 2 Build 9: aarch64/2019/oct/31 pass: 5,784; fail: 1 Build 10: aarch64/2019/nov/09 pass: 5,773; fail: 3 Build 11: aarch64/2019/nov/16 pass: 5,775; fail: 1 Build 12: aarch64/2019/nov/21 pass: 5,775; fail: 1 Build 13: aarch64/2019/dec/05 pass: 5,775; fail: 1 Build 14: aarch64/2019/dec/08 pass: 5,775; fail: 1 ------------------------------------------------------------------------------- release/jdk ------------------------------------------------------------------------------- Build 0: aarch64/2019/aug/15 pass: 8,443; fail: 496; error: 13 Build 1: aarch64/2019/aug/22 pass: 8,446; fail: 494; error: 15 Build 2: aarch64/2019/sep/04 pass: 8,483; fail: 465; error: 10 Build 3: aarch64/2019/sep/05 pass: 8,465; fail: 479; error: 14 Build 4: aarch64/2019/sep/10 pass: 8,444; fail: 500; error: 14 Build 5: aarch64/2019/sep/17 pass: 8,462; fail: 482; error: 12 Build 6: aarch64/2019/sep/21 pass: 8,467; fail: 478; error: 13 Build 7: aarch64/2019/oct/04 pass: 8,444; fail: 498; error: 16 Build 8: aarch64/2019/oct/17 pass: 8,452; fail: 493; error: 16 Build 9: aarch64/2019/oct/31 pass: 8,468; fail: 490; error: 14 Build 10: aarch64/2019/nov/09 pass: 8,487; fail: 470; error: 16 Build 11: aarch64/2019/nov/16 pass: 8,475; fail: 484; error: 15 Build 12: aarch64/2019/nov/21 pass: 8,489; fail: 497; error: 13 Build 13: aarch64/2019/dec/05 pass: 8,492; fail: 501; error: 11 Build 14: aarch64/2019/dec/08 pass: 8,482; fail: 505; error: 17 2 fatal errors were detected; please follow the link above for more detail. ------------------------------------------------------------------------------- release/langtools ------------------------------------------------------------------------------- Build 0: aarch64/2019/aug/15 pass: 3,909 Build 1: aarch64/2019/aug/22 pass: 3,909 Build 2: aarch64/2019/sep/04 pass: 3,910 Build 3: aarch64/2019/sep/05 pass: 3,910 Build 4: aarch64/2019/sep/10 pass: 3,910 Build 5: aarch64/2019/sep/17 pass: 3,910 Build 6: aarch64/2019/sep/21 pass: 3,910 Build 7: aarch64/2019/oct/04 pass: 3,910 Build 8: aarch64/2019/oct/17 pass: 3,910 Build 9: aarch64/2019/oct/31 pass: 3,910 Build 10: aarch64/2019/nov/09 pass: 3,910 Build 11: aarch64/2019/nov/16 pass: 3,910 Build 12: aarch64/2019/nov/21 pass: 3,910 Build 13: aarch64/2019/dec/05 pass: 3,910 Build 14: aarch64/2019/dec/08 pass: 3,910 Previous results can be found here: http://openjdk.linaro.org/jdk11u/openjdk-jtreg-nightly-tests/index.html SPECjbb2015 composite regression test completed =============================================== This test measures the relative performance of the server compiler running the SPECjbb2015 composite tests and compares the performance against the baseline performance of the server compiler taken on 2016-11-21. In accordance with [1], the SPECjbb2015 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): 7.38x Relative performance: Server critical-jOPS (nc): 8.03x Details of the test setup and historical results may be found here: http://openjdk.linaro.org/jdk11u/SPECjbb2015-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 server compiler on 2014-04-01. Relative performance: Zero: 1.0, Server: 213.86 Server 213.86 / Server 2014-04-01 (71.00): 3.01x Details of the test setup and historical results may be found here: http://openjdk.linaro.org/jdk11u/hadoop-terasort-benchmark-results/ This is a summary of the jcstress test results ============================================== The build and test results are cycled every 15 days. 2019-08-16 pass rate: 10489/10489, results: http://openjdk.linaro.org/jdk11u/jcstress-nightly-runs/2019/227/results/ 2019-08-23 pass rate: 10489/10489, results: http://openjdk.linaro.org/jdk11u/jcstress-nightly-runs/2019/234/results/ 2019-09-05 pass rate: 10489/10489, results: http://openjdk.linaro.org/jdk11u/jcstress-nightly-runs/2019/247/results/ 2019-09-07 pass rate: 10489/10489, results: http://openjdk.linaro.org/jdk11u/jcstress-nightly-runs/2019/248/results/ 2019-09-11 pass rate: 10489/10489, results: http://openjdk.linaro.org/jdk11u/jcstress-nightly-runs/2019/253/results/ 2019-09-18 pass rate: 10489/10489, results: http://openjdk.linaro.org/jdk11u/jcstress-nightly-runs/2019/260/results/ 2019-09-22 pass rate: 10489/10489, results: http://openjdk.linaro.org/jdk11u/jcstress-nightly-runs/2019/264/results/ 2019-10-05 pass rate: 10489/10489, results: http://openjdk.linaro.org/jdk11u/jcstress-nightly-runs/2019/277/results/ 2019-10-18 pass rate: 10489/10489, results: http://openjdk.linaro.org/jdk11u/jcstress-nightly-runs/2019/290/results/ 2019-11-01 pass rate: 10489/10489, results: http://openjdk.linaro.org/jdk11u/jcstress-nightly-runs/2019/304/results/ 2019-11-10 pass rate: 10490/10490, results: http://openjdk.linaro.org/jdk11u/jcstress-nightly-runs/2019/313/results/ 2019-11-17 pass rate: 10490/10490, results: http://openjdk.linaro.org/jdk11u/jcstress-nightly-runs/2019/320/results/ 2019-11-22 pass rate: 10490/10490, results: http://openjdk.linaro.org/jdk11u/jcstress-nightly-runs/2019/325/results/ 2019-12-07 pass rate: 10490/10490, results: http://openjdk.linaro.org/jdk11u/jcstress-nightly-runs/2019/339/results/ 2019-12-09 pass rate: 10490/10490, results: http://openjdk.linaro.org/jdk11u/jcstress-nightly-runs/2019/342/results/ For detailed information on the test output please refer to: http://openjdk.linaro.org/jdk11u/jcstress-nightly-runs/ From zhuoren.wz at alibaba-inc.com Mon Dec 9 08:51:51 2019 From: zhuoren.wz at alibaba-inc.com (=?UTF-8?B?V2FuZyBaaHVvKFpodW9yZW4p?=) Date: Mon, 09 Dec 2019 16:51:51 +0800 Subject: [aarch64-port-dev ] =?utf-8?q?_crash_due_to_long_offset?= Message-ID: <2d65a25f-8e38-4da4-a6ef-b4ff9ba847fe.zhuoren.wz@alibaba-inc.com> Hi, I am an engineer from Alibaba. Here is a crash we observed days before. # Internal Error (assembler_aarch64.hpp:251), pid=125009, tid=125020 # guarantee(chk == -1 || chk == 0) failed: Field too big for insn Detailed information is in https://bugs.openjdk.java.net/browse/JDK-8235385?filter=-2 There was a simple test in the bug report. You can reproduce the crash on 8u/11u/tip. I also wrote a patch to solve this issue, please also review. http://cr.openjdk.java.net/~wzhuo/BigOffsetAarch64/webrev.00/jdk13u.patch Regards, Zhuoren From rkennke at redhat.com Mon Dec 9 14:33:02 2019 From: rkennke at redhat.com (Roman Kennke) Date: Mon, 9 Dec 2019 15:33:02 +0100 Subject: [aarch64-port-dev ] RFR: Bulk integration from shenandoah/jdk8 Message-ID: Hello all, I'd like to propose integration of outstanding changes and backports from shenandoah/jdk8. This time it is rather big. Most significantly, it includes LRB, elimination of forwarding pointer, the new x86_32 port, the Traversal GC, plus a whole lot of related bugfixes. The list of changes: http://cr.openjdk.java.net/~rkennke/aarch64-shenandoah-integration-2019-12-09/changesets.txt Shared-only webrev: http://cr.openjdk.java.net/~rkennke/aarch64-shenandoah-integration-2019-12-09/webrev-shared-only.00/ Full webrev: http://cr.openjdk.java.net/~rkennke/aarch64-shenandoah-integration-2019-12-09/webrev-all.00/ There are quite many shared-code changes involved in this. However, most of them actually revert/remove existing shared-code changes vs upstream jdk8u, so the net effect is a drastic improvement. We added a few new hooks (for the LRB), but we kept it inside the following pattern wherever possible: #ifdef INCLUDE_ALL_GCS if (UseShenandoahGC) {... } #endif Also, this change includes some renaming and moving-around of (Shenandoah) files to keep Shenandoah code in Shenandoah subdirectories, and follow the naming scheme of >=11 as much as possible. Can I please get a review of this? Thanks, Roman From rkennke at redhat.com Mon Dec 9 14:34:47 2019 From: rkennke at redhat.com (Roman Kennke) Date: Mon, 9 Dec 2019 15:34:47 +0100 Subject: [aarch64-port-dev ] RFR: Bulk integration from shenandoah/jdk8 In-Reply-To: References: Message-ID: <3fecb6dd-f745-1bbb-6d7b-5c9a3225f0fe@redhat.com> I forgot to mention: this has baked in shenandoah/jdk8 for a couple of weeks now, gone through our CI many times, has been tested manually for equally many times, and I believe some early adopters have also picked it up and run with success. It also comes with a whole lot of new and improved tests under gc/shenandoah. Roman > Hello all, > > I'd like to propose integration of outstanding changes and backports > from shenandoah/jdk8. > > This time it is rather big. Most significantly, it includes LRB, > elimination of forwarding pointer, the new x86_32 port, the Traversal > GC, plus a whole lot of related bugfixes. > > The list of changes: > http://cr.openjdk.java.net/~rkennke/aarch64-shenandoah-integration-2019-12-09/changesets.txt > > Shared-only webrev: > http://cr.openjdk.java.net/~rkennke/aarch64-shenandoah-integration-2019-12-09/webrev-shared-only.00/ > > Full webrev: > http://cr.openjdk.java.net/~rkennke/aarch64-shenandoah-integration-2019-12-09/webrev-all.00/ > > There are quite many shared-code changes involved in this. However, most > of them actually revert/remove existing shared-code changes vs upstream > jdk8u, so the net effect is a drastic improvement. We added a few new > hooks (for the LRB), but we kept it inside the following pattern > wherever possible: > > #ifdef INCLUDE_ALL_GCS > if (UseShenandoahGC) {... > } > #endif > > Also, this change includes some renaming and moving-around of > (Shenandoah) files to keep Shenandoah code in Shenandoah subdirectories, > and follow the naming scheme of >=11 as much as possible. > > Can I please get a review of this? > > Thanks, > Roman > From patrick at os.amperecomputing.com Tue Dec 10 05:43:38 2019 From: patrick at os.amperecomputing.com (Patrick Zhang OS) Date: Tue, 10 Dec 2019 05:43:38 +0000 Subject: [aarch64-port-dev ] RFR (trivial): 8234228: AArch64: Clean up redundant temp vars in generate_compare_long_string_different_encoding In-Reply-To: References: Message-ID: Could anyone help review this patch, thanks. JBS: https://bugs.openjdk.java.net/browse/JDK-8234228 Webrev: http://cr.openjdk.java.net/~qpzhang/8234228/webrev.01 Regards Patrick -----Original Message----- From: hotspot-compiler-dev On Behalf Of Patrick Zhang OS Sent: Monday, December 2, 2019 11:19 AM To: aarch64-port-dev at openjdk.java.net Cc: hotspot-compiler-dev at openjdk.java.net Subject: RE: RFR (trivial): 8234228: AArch64: Clean up redundant temp vars in generate_compare_long_string_different_encoding Ping... Please help review, thanks. Regards Patrick -----Original Message----- From: hotspot-compiler-dev On Behalf Of Patrick Zhang OS Sent: Friday, November 15, 2019 6:54 PM To: hotspot-compiler-dev at openjdk.java.net; aarch64-port-dev at openjdk.java.net Subject: RFR (trivial): 8234228: AArch64: Clean up redundant temp vars in generate_compare_long_string_different_encoding Hi Reviewers, This is a simple patch which cleans up some redundant temp vars and related instructions in generate_compare_long_string_different_encoding. JBS: https://bugs.openjdk.java.net/browse/JDK-8234228 Webrev: http://cr.openjdk.java.net/~qpzhang/8234228/webrev.01 In generate_compare_long_string_different_encoding, the two Register vars strU and strL were used to record the pointers of the last 4 characters for the final comparisons. strU has been no use since the latest code updates as the chars got pre-loaded (r12) by compare_string_16_x_LU early, and strL is redundant too since the pointer is available in r11. Cleaning up these can save two add, two temp vars, and replace two sub with mov. In addition, r10 in compare_string_16_x_LU is not used, cleaned the temp var too. Tested jtreg tier1, and hotspot runtime/compiler, no new failures found. Double checked with string intrinsics cases under [1], no regression found. Ran [2] CompareToBench LU/UL as performance check, no regression found, and slight gains with some input sizes [1] http://hg.openjdk.java.net/jdk/jdk/file/3df2bf731a87/test/hotspot/jtreg/compiler/intrinsics/string [2] http://cr.openjdk.java.net/~shade/density/string-density-bench.jar Regards Patrick From patrick at os.amperecomputing.com Tue Dec 10 05:49:44 2019 From: patrick at os.amperecomputing.com (Patrick Zhang OS) Date: Tue, 10 Dec 2019 05:49:44 +0000 Subject: [aarch64-port-dev ] RFR: 8229351: AArch64: Make the stub threshold of string_compare intrinsic tunable In-Reply-To: References: Message-ID: Please help review this patch (updated), thanks. JBS: https://bugs.openjdk.java.net/browse/JDK-8229351 Webrev: http://cr.openjdk.java.net/~qpzhang/8229351/webrev.05 Regards Patrick -----Original Message----- From: aarch64-port-dev On Behalf Of Patrick Zhang OS Sent: Thursday, November 28, 2019 11:12 AM To: Andrew Haley ; Andrew Dinn Cc: aarch64-port-dev at openjdk.java.net Subject: Re: [aarch64-port-dev ] RFR: 8229351: AArch64: Make the stub threshold of string_compare intrinsic tunable Hi Andrew, I collected the timings and did a comparison, please see the spread sheet in [1]. Per the comments from Dmitrij in another thread, and rethought the concerns you and Andrew Dinn reminded, I revised the patch to drop the tunable flags and the extra overprefech checking for LL/UU, then updated the shared STUB_THRESHOLD for UU/LU/UL respectively, according to the experimental data (but note that I only have one aarch64 system, the coverage might be limited). Please review. JBS: https://bugs.openjdk.java.net/browse/JDK-8229351 Webrev: http://cr.openjdk.java.net/~qpzhang/8229351/webrev.05 1. LL is the most common use case, especially the shorter strings, I will not change this as the tests cannot consistently produce a very positive data. So this part is same as what Dmitrij worked on, nothing changed. 2. UU used the same threshold 72 (chars) as LL, which meant 144 bytes for UU and 72 bytes for LL (with -XX:+CompactStrings by default). I updated it from 72 to 36 so the limit is fair to UU now. The test shows (see figure [2]) there is in average ~10% perf gains with [36, 71] characters, other lengths are same. 3. LU/UL, updated the threshold from 72 (chars) to 24 (chars). According to the algorithm in generate_compare_long_string_different_encoding, 24 is the minimum length that can take the advantage of compare_string_16_x_LU function to process 16 chars (32 bytes) in a loop, and can be faster than the outer function which processes every 8 bytes in the main loop. See figure [3], the perf gains are up to 60% (the secondary axis at the right) 4. Added " align(OptoLoopAlignment);" for main loops in the stub code, per early suggestions from Aleksei. 5. Updated the two relevant test cases under test/hotspot/jtreg/compiler/intrinsics/string, with additional string lengths that can better cover the cases referred in this patch. More about the figures in the spread sheet and the JPG files (same): The lengths are scatter points [4] suggested by Andrew, the main axis (at left) shows the times (multiplied by a const, so don't use the absolute values with ns/op), the blue dots shows the base trend, the orange dots belong to the patch, while the yellow dots (secondary axis) stand for the perf gains (patch vs base). For example, in [3], with the patch, the orange curve (patch) becomes be "monotonically increasing" with [24, 71] chars, which is better than the shape of blue curve (base) and it is what I (we) want. Tests: jtreg tier1 all, hotspot_all, string-density-bench.jar, no regression found. [1] http://cr.openjdk.java.net/~qpzhang/8229351/8229351-strcmp-perf.xlsx [2] http://cr.openjdk.java.net/~qpzhang/8229351/perf-strcmp-UU.JPG [3] http://cr.openjdk.java.net/~qpzhang/8229351/perf-strcmp-LU.JPG [4] tested sampling points (lengths of strings): 1, 2, 3, 4, 5, 6, 7, 8, 9, 10, 11, 13, 14, 15, 17, 19, 21, 23, 25, 28, 30, 34, 37, 41, 45, 49, 54, 60, 66, 72, 80, 88, 97, 106, 117, 129, 142, 156, 171, 189, 207, 228, 251 Regards Patrick -----Original Message----- From: aarch64-port-dev On Behalf Of Patrick Zhang OS Sent: Friday, November 15, 2019 4:05 PM To: Andrew Haley ; Andrew Dinn Cc: aarch64-port-dev at openjdk.java.net Subject: Re: [aarch64-port-dev ] RFR: 8229351: AArch64: Make the stub threshold of string_compare intrinsic tunable To avoid future confusion, I am going to split the patch, take out the updates for generate_compare_long_string_different_encoding, which drops two redundant temp Register vars and related unused instructions, then create a new for your review. It has nothing to do with the proposed option. And I will continue working the remaining parts according to your comments and suggestions.. Regards Patrick -----Original Message----- From: aarch64-port-dev On Behalf Of Patrick Zhang OS Sent: Thursday, November 14, 2019 7:14 PM To: Andrew Haley ; aarch64-port-dev at openjdk.java.net Subject: Re: [aarch64-port-dev ] RFR: 8229351: AArch64: Make the stub threshold of string_compare intrinsic tunable >> Why do we care about out-of-boundary prefetching for LL/UU? I don't think we do if it requires any extra logic. I was thinking out-of-boundary prefetching should be prevented, and UL/LU has the same condition, if no need, we could force set largeLoopExitCondition to be 64 so that more cases can freely stay in the large loop. I don't think so. http://hg.openjdk.java.net/jdk/jdk/file/355f4f42dda5/src/hotspot/cpu/aarch64/stubGenerator_aarch64.cpp#l4194 if (SoftwarePrefetchHintDistance >= 0) { __ bind(LARGE_LOOP_PREFETCH); __ prfm(Address(str1, SoftwarePrefetchHintDistance)); __ prfm(Address(str2, SoftwarePrefetchHintDistance)); compare_string_16_bytes_same(DIFF, DIFF2); compare_string_16_bytes_same(DIFF, DIFF2); __ sub(cnt2, cnt2, isLL ? 64 : 32); compare_string_16_bytes_same(DIFF, DIFF2); - __ subs(rscratch2, cnt2, largeLoopExitCondition); + __ subs(rscratch2, cnt2, 64); compare_string_16_bytes_same(DIFF, DIFF2); __ br(__ GT, LARGE_LOOP_PREFETCH); __ cbz(cnt2, LAST_CHECK_AND_LENGTH_DIFF); // no more chars left? } >> Do you have a theory that LU/UL cases are common? Why? The only "theory" can be compare_string_16_x_LU (in the stub) is fater than the 8 bytes main loop (out of the stub) (http://hg.openjdk.java.net/jdk/jdk/file/355f4f42dda5/src/hotspot/cpu/aarch64/macroAssembler_aarch64.cpp#l4997), even not in the large loop of stub, the small loop can be faster as well since it is able to process more bytes within fewer instructions (http://hg.openjdk.java.net/jdk/jdk/file/355f4f42dda5/src/hotspot/cpu/aarch64/stubGenerator_aarch64.cpp#l4203). I can prepare a new patch with the updates to tests, and plot the timings soon latter. Regards Patrick -----Original Message----- From: Andrew Haley Sent: Thursday, November 14, 2019 6:33 PM To: Patrick Zhang OS ; aarch64-port-dev at openjdk.java.net Subject: Re: [aarch64-port-dev ] RFR: 8229351: AArch64: Make the stub threshold of string_compare intrinsic tunable On 11/14/19 9:20 AM, Patrick Zhang OS wrote: > Thanks for the comments, see my answers below please. > >>> 1. This patch seems to do rather a lot. > Yes, it enables tweaking the stub parameters (not really changed any > in this patch), fixed an out-of-boundary prefetching for LL/UU, and > fixed some redundant instructions in LU/UL code path. The latter two > are code-quality-wise, if splitting the patch could make the changes > clearer, I'd like to do. Why do we care about out-of-boundary prefetching for LL/UU? I don't think we do if it requires any extra logic. >>> 2. Are the thresholds bytes or characters? > All thresholds are (and should be) in characters. This was a little > bit misleading, for LL/LU/UL, the const STUB_THRESHOLD meant chars, > while for UU it could be explained as bytes. If specified > -XX:-CompactStrings, all code path going to UU would make the > threshold mean bytes, which might confuse developers. This patch can > clarify it, and the description of tunable options can provide further > guidance. It must. Without some commentary both maintainers and developers are lost. Unless there is some very strong reason, all counts must specify units. >>> 3. How are we supposed to test with these different thresholds? > There are two jtreg tests for checking the impacts of > SoftwarePrefetchHintDistance over the intrinsics, I have locally added > non-default thresholds inside and tested with many lengths (took days > on a test system). This has not been included in the proposed patch, > maybe a follow-up one would do, any advice? > hotspot/jtreg/compiler/intrinsics/string/TestStringCompareToSameLength > .java > hotspot/jtreg/compiler/intrinsics/string/TestStringCompareToDifferentL > ength.java I won't accept this patch unless it is accompanied by test cases that properly exercise the code. >>> 4. What are the thresholds you tested? > Firstly, the default threshold, the hardcoded 72 is my testing focus > since I would try best not to bring negative impacts to aarch64-port > normal state, especially other CPU vendors. > Second, I tested two extreme thresholds: 24 and 255, which means more > shorter strings (24 to 71 chars) or only very long strings > (>=255) could go to the stub code path, respectively. Function tests > passed (listed in the initial email), while performance test results > (with string-density-bench, StringCompareBench.java, and > SPECjbb2015) could be varying with different systems (as well as > microarchitectures). > Third, some other non-default thresholds, as sanity check, > particularly for ensuring correctness. It's the extremes that really matter, I suspect. >>> 5. But the more serious problem is the fact that we have different >>> code paths for different microarchitectures, and somehow this has to >>> be standard supportable software. In order to test this stuff we'll >>> need different test parameters for SoftwarePrefetchHintDistance, >>> CompareLongStringLimitLatin, CompareLongStringLimitUTF > The STUB_THRESHOLD was introduced to control the stub code insertion, > tested on some aarch64 systems. I think making it tunable is the way > to let different microarchitectures be able to configure optimal ones > for their own. Well, yes. The question is whether we go down this rabbit hole or try to find a compromise that is perhaps not quite optimal for anyone but good enough for everyone. > I would like to have a common threshold too, or no threshold for all, > but lacking of full-coverage tests over all systems. Maybe I > misunderstood you points here with regards to "supportable", the two > new options can be kept as default if developers have no concerns on > string compare intrinsics. I rather suspect that vendors will want to change the defaults sooner or later. And besides, we'll all have to support these options. >>> 6. We already emit a great deal of in-line code in the >>> string_compare intrinsic, with the intention that this be as fast as >>> possible because we want to avoid having to call the intrinsic. So >>> why is the intrinsic actually faster in your case? > Avoid having to call the intrinsic? I meant "the stub". > If you did NOT mean completely "avoiding intrinsic", but the strings > shorter than 72 chars, I would have to say, "it depends". The stub > functions try best to process every 16 chars, while the outer logic > processes every 8 bytes, which is the major diff. For example, I can > see consistent 1.5x faster with lengths 24-71 for LU/UL cases, maybe > others cannot, which can be reason why we need an option here. I know that strings of length 24 - 30ish are very common, so this is an important case. Do you have a theory that LU/UL cases are common? Why? What is it like with LL/UU? I'd need to see real timings. I'd either do all numbers < 256 or (to save time) a sequence like... 1, 2, 3, 4, 5, 6, 7, 8, 9, 10, 11, 13, 14, 15, 17, 19, 21, 23, 25, 28, 30, 34, 37, 41, 45, 49, 54, 60, 66, 72, 80, 88, 97, 106, 117, 129, 142, 156, 171, 189, 207, 228, 251 The idea here is that we an plot a graph. The timings should ideally be monotonically increasing. And then we could see how different processors behave, and hopefully find a decent solution for all. -- Andrew Haley (he/him) Java Platform Lead Engineer Red Hat UK Ltd. https://keybase.io/andrewhaley EAC8 43EB D3EF DB98 CC77 2FAD A5CD 6035 332F A671 From Pengfei.Li at arm.com Tue Dec 10 08:28:57 2019 From: Pengfei.Li at arm.com (Pengfei Li (Arm Technology China)) Date: Tue, 10 Dec 2019 08:28:57 +0000 Subject: [aarch64-port-dev ] crash due to long offset In-Reply-To: <2d65a25f-8e38-4da4-a6ef-b4ff9ba847fe.zhuoren.wz@alibaba-inc.com> References: <2d65a25f-8e38-4da4-a6ef-b4ff9ba847fe.zhuoren.wz@alibaba-inc.com> Message-ID: Hi Zhuoren, > I also wrote a patch to solve this issue, please also review. > http://cr.openjdk.java.net/~wzhuo/BigOffsetAarch64/webrev.00/jdk13u.pat > ch Thanks for your patch. I (NOT a reviewer) eyeballed your fix and found a probable mistake. In "enc_class aarch64_enc_str(iRegL src, memory mem) %{ ... %}", you have "if (($mem$$index == -1) && ($mem$$disp > 0)& (($mem$$disp & 0x7) != 0) && ($mem$$disp > 255))". Should it be "&&" instead of "&" in the middle? Another question: Is it possible to add the logic into loadStore() or another new function instead of duplicating it everywhere in aarch64.ad? I've also CC'ed this to hotspot-compiler-dev because all hotspot compiler patches (including AArch64 specific) should go through it for review. -- Thanks, Pengfei From ci_notify at linaro.org Tue Dec 10 11:01:37 2019 From: ci_notify at linaro.org (ci_notify at linaro.org) Date: Tue, 10 Dec 2019 11:01:37 +0000 (UTC) Subject: [aarch64-port-dev ] JTREG, JCStress, SPECjbb2015 and Hadoop/Terasort results for OpenJDK JDK on AArch64 Message-ID: <886193118.4174.1575975698571.JavaMail.javamailuser@localhost> This is a summary of the JTREG test results =========================================== The build and test results are cycled every 15 days. For detailed information on the test output please refer to: http://openjdk.linaro.org/jdkX/openjdk-jtreg-nightly-tests/summary/2019/343/summary.html ------------------------------------------------------------------------------- client-release/hotspot ------------------------------------------------------------------------------- Build 0: aarch64/2018/oct/15 pass: 5,780; fail: 19; not run: 90 ------------------------------------------------------------------------------- client-release/jdk ------------------------------------------------------------------------------- Build 0: aarch64/2018/oct/15 pass: 8,495; fail: 670; error: 23 ------------------------------------------------------------------------------- client-release/langtools ------------------------------------------------------------------------------- Build 0: aarch64/2018/oct/15 pass: 3,970; fail: 5 ------------------------------------------------------------------------------- release/hotspot ------------------------------------------------------------------------------- Build 0: aarch64/2019/nov/06 pass: 5,766; fail: 2 Build 1: aarch64/2019/nov/08 pass: 5,761 Build 2: aarch64/2019/nov/11 pass: 5,762 Build 3: aarch64/2019/nov/13 pass: 5,764; fail: 1 Build 4: aarch64/2019/nov/15 pass: 5,750 Build 5: aarch64/2019/nov/18 pass: 5,750; fail: 1 Build 6: aarch64/2019/nov/20 pass: 5,752 Build 7: aarch64/2019/nov/22 pass: 5,752; fail: 1 Build 8: aarch64/2019/nov/25 pass: 5,752; fail: 1 Build 9: aarch64/2019/nov/27 pass: 5,752; fail: 2 Build 10: aarch64/2019/nov/29 pass: 5,752; fail: 2 Build 11: aarch64/2019/dec/02 pass: 5,753; fail: 4 Build 12: aarch64/2019/dec/04 pass: 5,755; fail: 2 Build 13: aarch64/2019/dec/07 pass: 5,762; fail: 1 Build 14: aarch64/2019/dec/09 pass: 5,762; fail: 1 1 fatal errors were detected; please follow the link above for more detail. ------------------------------------------------------------------------------- release/jdk ------------------------------------------------------------------------------- Build 0: aarch64/2019/nov/06 pass: 8,775; fail: 507; error: 19 Build 1: aarch64/2019/nov/08 pass: 8,774; fail: 510; error: 17 Build 2: aarch64/2019/nov/11 pass: 8,777; fail: 509; error: 15 Build 3: aarch64/2019/nov/13 pass: 8,773; fail: 509; error: 21 Build 4: aarch64/2019/nov/15 pass: 8,756; fail: 511; error: 19 Build 5: aarch64/2019/nov/18 pass: 8,765; fail: 504; error: 18 Build 6: aarch64/2019/nov/20 pass: 8,768; fail: 504; error: 19 Build 7: aarch64/2019/nov/22 pass: 8,769; fail: 507; error: 18 Build 8: aarch64/2019/nov/25 pass: 8,775; fail: 509; error: 17 Build 9: aarch64/2019/nov/27 pass: 8,779; fail: 506; error: 22 Build 10: aarch64/2019/nov/29 pass: 8,784; fail: 503; error: 20 Build 11: aarch64/2019/dec/02 pass: 8,784; fail: 507; error: 19 Build 12: aarch64/2019/dec/04 pass: 8,788; fail: 505; error: 17 Build 13: aarch64/2019/dec/07 pass: 8,819; fail: 524; error: 17 Build 14: aarch64/2019/dec/09 pass: 8,820; fail: 519; error: 21 5 fatal errors were detected; please follow the link above for more detail. ------------------------------------------------------------------------------- release/langtools ------------------------------------------------------------------------------- Build 0: aarch64/2019/nov/06 pass: 3,980 Build 1: aarch64/2019/nov/08 pass: 3,980 Build 2: aarch64/2019/nov/11 pass: 3,980 Build 3: aarch64/2019/nov/13 pass: 3,980 Build 4: aarch64/2019/nov/15 pass: 3,981 Build 5: aarch64/2019/nov/18 pass: 3,981 Build 6: aarch64/2019/nov/20 pass: 3,981 Build 7: aarch64/2019/nov/22 pass: 3,981 Build 8: aarch64/2019/nov/25 pass: 3,983 Build 9: aarch64/2019/nov/27 pass: 4,006 Build 10: aarch64/2019/nov/29 pass: 4,006 Build 11: aarch64/2019/dec/02 pass: 4,002; fail: 5; error: 1 Build 12: aarch64/2019/dec/04 pass: 4,008 Build 13: aarch64/2019/dec/07 pass: 4,019 Build 14: aarch64/2019/dec/09 pass: 4,019 ------------------------------------------------------------------------------- server-release/hotspot ------------------------------------------------------------------------------- Build 0: aarch64/2018/oct/15 pass: 5,787; fail: 18; not run: 90 ------------------------------------------------------------------------------- server-release/jdk ------------------------------------------------------------------------------- Build 0: aarch64/2018/oct/15 pass: 8,476; fail: 686; error: 27 ------------------------------------------------------------------------------- server-release/langtools ------------------------------------------------------------------------------- Build 0: aarch64/2018/oct/15 pass: 3,970; fail: 5 Previous results can be found here: http://openjdk.linaro.org/jdkX/openjdk-jtreg-nightly-tests/index.html SPECjbb2015 composite regression test completed =============================================== This test measures the relative performance of the server compiler running the SPECjbb2015 composite tests and compares the performance against the baseline performance of the server compiler taken on 2016-11-21. In accordance with [1], the SPECjbb2015 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): 7.83x Relative performance: Server critical-jOPS (nc): 10.21x Details of the test setup and historical results may be found here: http://openjdk.linaro.org/jdkX/SPECjbb2015-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 server compiler on 2014-04-01. Relative performance: Zero: 1.0, Server: 207.57 Server 207.57 / Server 2014-04-01 (71.00): 2.92x Details of the test setup and historical results may be found here: http://openjdk.linaro.org/jdkX/hadoop-terasort-benchmark-results/ This is a summary of the jcstress test results ============================================== The build and test results are cycled every 15 days. 2019-11-05 pass rate: 10489/10489, results: http://openjdk.linaro.org/jdkX/jcstress-nightly-runs/2019/308/results/ 2019-11-07 pass rate: 10490/10490, results: http://openjdk.linaro.org/jdkX/jcstress-nightly-runs/2019/310/results/ 2019-11-12 pass rate: 10490/10490, results: http://openjdk.linaro.org/jdkX/jcstress-nightly-runs/2019/315/results/ 2019-11-14 pass rate: 10490/10490, results: http://openjdk.linaro.org/jdkX/jcstress-nightly-runs/2019/317/results/ 2019-11-16 pass rate: 10490/10490, results: http://openjdk.linaro.org/jdkX/jcstress-nightly-runs/2019/319/results/ 2019-11-19 pass rate: 10490/10490, results: http://openjdk.linaro.org/jdkX/jcstress-nightly-runs/2019/322/results/ 2019-11-21 pass rate: 10490/10490, results: http://openjdk.linaro.org/jdkX/jcstress-nightly-runs/2019/324/results/ 2019-11-23 pass rate: 10490/10490, results: http://openjdk.linaro.org/jdkX/jcstress-nightly-runs/2019/326/results/ 2019-11-26 pass rate: 10490/10490, results: http://openjdk.linaro.org/jdkX/jcstress-nightly-runs/2019/329/results/ 2019-12-03 pass rate: 10490/10490, results: http://openjdk.linaro.org/jdkX/jcstress-nightly-runs/2019/331/results/ 2019-12-04 pass rate: 10490/10490, results: http://openjdk.linaro.org/jdkX/jcstress-nightly-runs/2019/333/results/ 2019-12-05 pass rate: 10490/10490, results: http://openjdk.linaro.org/jdkX/jcstress-nightly-runs/2019/336/results/ 2019-12-07 pass rate: 10490/10490, results: http://openjdk.linaro.org/jdkX/jcstress-nightly-runs/2019/338/results/ 2019-12-08 pass rate: 10490/10490, results: http://openjdk.linaro.org/jdkX/jcstress-nightly-runs/2019/341/results/ 2019-12-10 pass rate: 10490/10490, results: http://openjdk.linaro.org/jdkX/jcstress-nightly-runs/2019/343/results/ For detailed information on the test output please refer to: http://openjdk.linaro.org/jdkX/jcstress-nightly-runs/ From aph at redhat.com Tue Dec 10 14:05:25 2019 From: aph at redhat.com (Andrew Haley) Date: Tue, 10 Dec 2019 14:05:25 +0000 Subject: [aarch64-port-dev ] crash due to long offset In-Reply-To: References: <2d65a25f-8e38-4da4-a6ef-b4ff9ba847fe.zhuoren.wz@alibaba-inc.com> Message-ID: <26ad8b0f-95a6-f126-7ea1-aa59291145d4@redhat.com> On 12/10/19 8:28 AM, Pengfei Li (Arm Technology China) wrote: > Hi Zhuoren, > >> I also wrote a patch to solve this issue, please also review. >> http://cr.openjdk.java.net/~wzhuo/BigOffsetAarch64/webrev.00/jdk13u.pat >> ch > Thanks for your patch. I (NOT a reviewer) eyeballed your fix and found a probable mistake. > > In "enc_class aarch64_enc_str(iRegL src, memory mem) %{ ... %}", you have "if (($mem$$index == -1) && ($mem$$disp > 0)& (($mem$$disp & 0x7) != 0) && ($mem$$disp > 255))". > Should it be "&&" instead of "&" in the middle? > > Another question: Is it possible to add the logic into loadStore() or another new function instead of duplicating it everywhere in aarch64.ad? > > I've also CC'ed this to hotspot-compiler-dev because all hotspot compiler patches (including AArch64 specific) should go through it for review. I'm looking at this. -- Andrew Haley (he/him) Java Platform Lead Engineer Red Hat UK Ltd. https://keybase.io/andrewhaley EAC8 43EB D3EF DB98 CC77 2FAD A5CD 6035 332F A671 From zhuoren.wz at alibaba-inc.com Tue Dec 10 15:43:23 2019 From: zhuoren.wz at alibaba-inc.com (=?UTF-8?B?V2FuZyBaaHVvKFpodW9yZW4p?=) Date: Tue, 10 Dec 2019 23:43:23 +0800 Subject: [aarch64-port-dev ] =?utf-8?q?crash_due_to_long_offset?= In-Reply-To: <26ad8b0f-95a6-f126-7ea1-aa59291145d4@redhat.com> References: <2d65a25f-8e38-4da4-a6ef-b4ff9ba847fe.zhuoren.wz@alibaba-inc.com> , <26ad8b0f-95a6-f126-7ea1-aa59291145d4@redhat.com> Message-ID: Pengfei, thanks for your comments. Here is updated patch. http://cr.openjdk.java.net/~wzhuo/BigOffsetAarch64/webrev.01/ Haley, please also have a look at this patch. Regards, Zhuoren ------------------------------------------------------------------ From:Andrew Haley Sent At:2019 Dec. 10 (Tue.) 22:06 To:Pengfei Li (Arm Technology China) Cc:hotspot compiler ; aarch64-port-dev at openjdk.java.net Subject:Re: [aarch64-port-dev ] crash due to long offset On 12/10/19 8:28 AM, Pengfei Li (Arm Technology China) wrote: > Hi Zhuoren, > >> I also wrote a patch to solve this issue, please also review. >> http://cr.openjdk.java.net/~wzhuo/BigOffsetAarch64/webrev.00/jdk13u.pat >> ch > Thanks for your patch. I (NOT a reviewer) eyeballed your fix and found a probable mistake. > > In "enc_class aarch64_enc_str(iRegL src, memory mem) %{ ... %}", you have "if (($mem$$index == -1) && ($mem$$disp > 0)& (($mem$$disp & 0x7) != 0) && ($mem$$disp > 255))". > Should it be "&&" instead of "&" in the middle? > > Another question: Is it possible to add the logic into loadStore() or another new function instead of duplicating it everywhere in aarch64.ad? > > I've also CC'ed this to hotspot-compiler-dev because all hotspot compiler patches (including AArch64 specific) should go through it for review. I'm looking at this. -- Andrew Haley (he/him) Java Platform Lead Engineer Red Hat UK Ltd. https://keybase.io/andrewhaley EAC8 43EB D3EF DB98 CC77 2FAD A5CD 6035 332F A671 From nick.gasson at arm.com Wed Dec 11 07:08:22 2019 From: nick.gasson at arm.com (Nick Gasson) Date: Wed, 11 Dec 2019 15:08:22 +0800 Subject: [aarch64-port-dev ] RFR: 8234794: AArch64: runtime/memory/ReadFromNoaccessArea.java crashes Message-ID: Hi, Please help to review this patch to fix some issues uncovered by CDS archive relocation. Bug: https://bugs.openjdk.java.net/browse/JDK-8234794 Webrev: http://cr.openjdk.java.net/~ngasson/8234794/webrev.01/ As a bit of background, on AArch64 there are a few different ways we can decode/encode compressed klass pointers, depending on the base address alignment and shift. (1) If the base is NULL then it's a no-op or shift. (2) If we can encode the the base as a logical immediate, use an EOR instruction to encode/decode. (3) If the base is 4G aligned and the shift is zero, use a MOVK instruction to combine the base and offset. (4) Otherwise emit an inefficient sequence using rheapbase as a temporary, and then restore the heap base (poorly tested). On AArch64 and AIX we have a loop in Metaspace::allocate_metaspace_compressed_klass_ptrs that searches for a 4G aligned location to map the compressed class space and enable optimisations (2) and (3) above. It's possible to fail and fall through to (4) after mmap-ing at an arbitrary address, but I think in practice this never happens. MetaspaceShared allocates the compressed class space in a different way, but the default base address is 0x80000000 which allows method (2) above. After the changes in 8231610 the CDS archive can be relocated to an arbitrary location decided by mmap, which makes case (4) much more likely. The test case in the title passes -XX:HeapBaseMinAddress=33g which triggers the CDS relocation. The combination of (4) and the extra shift/add from the non-NULL narrow OOP base overflows the itable stub code buffer. I want to fix this by ensuring that the compressed klass space is always at least 4G aligned on AArch64 so we can get rid of (4). This will reduce the variability in code size from memory layout, reduce the number of configurations we need to test, and makes repurposing rheapbase easier (see the review thread for 8233743). This patch moves the AArch64/AIX address space search loop into a new function Metaspace::reserve_preferred_space. MetaspaceShared::reserve_shared_space now calls this rather than directly constructing the ReservedSpace. If use_requested_addr is false it will search for a suitably aligned location (replacement for ReservedSpace() with requested_addr=NULL), otherwise it checks the fixed address meets the alignment requirements. Should be no functional change on platforms other than AArch64 and AIX. Additionally, to support method (3) when the compressed klass shift is non-zero (which it always is when CDS is on), the compressed klass base will be aligned to a (4 << LogKlassAlignmentInBytes)*G boundary when the base is above 32GB (limit for zero-based address). This allows us to shift the base address right LogKlassAlignmentInBytes bits and use MOVK to add it to the offset (discarding the lower 32 bits). I added an extra case to SharedBaseAddress.java to cover this during jtreg testing. Finally there's a small bug in the existing code to determine if we can use the EOR optimisation (2). use_XOR_for_compressed_class_base = operand_valid_for_logical_immediate (/*is32*/false, (uint64_t)CompressedKlassPointers::base()) && ((uint64_t)CompressedKlassPointers::base() > (1UL << log2_intptr(CompressedKlassPointers::range()))); This doesn't work if e.g. the base is 0x180000000 and the rounded-up range is 0x100000000 because the high significant bits of the compressed pointer overlap with the low significant bits of the base, even though the base is strictly greater than the range. So the following will SEGV with the current VM: java -Xmx128m -XX:SharedBaseAddress=6g -Xshare:dump Fixed this and moved all the logic for deciding which scheme to use into MacroAssembler::klass_decode_mode. Tested jtreg hotspot_all_no_apps, jdk_core on AArch64 and x86. Also did some manual testing with -XX:SharedBaseAddress and -XX:ArchiveRelocationMode=1 (thanks Ioi). I'm not able to test on AIX which shares the same metaspace code (CC'd ppc-aix-port-dev). Thanks, Nick From adinn at redhat.com Wed Dec 11 10:12:48 2019 From: adinn at redhat.com (Andrew Dinn) Date: Wed, 11 Dec 2019 10:12:48 +0000 Subject: [aarch64-port-dev ] RFR: 8234794: AArch64: runtime/memory/ReadFromNoaccessArea.java crashes In-Reply-To: References: Message-ID: <602ae7dc-c58d-aa64-841b-f6bc3c2cce93@redhat.com> Hi Nick, On 11/12/2019 07:08, Nick Gasson wrote: > Please help to review this patch to fix some issues uncovered by CDS > archive relocation. > > Bug: https://bugs.openjdk.java.net/browse/JDK-8234794 > Webrev: http://cr.openjdk.java.net/~ngasson/8234794/webrev.01/ . . . > Tested jtreg hotspot_all_no_apps, jdk_core on AArch64 and x86. Also did > some manual testing with -XX:SharedBaseAddress and > -XX:ArchiveRelocationMode=1 (thanks Ioi). > > I'm not able to test on AIX which shares the same metaspace code (CC'd > ppc-aix-port-dev). Nice work. It looks good enough to me to push. However, first it would only be right to have a review (and a sanity check test) from a ppc dev. 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 From aph at redhat.com Wed Dec 11 18:34:26 2019 From: aph at redhat.com (Andrew Haley) Date: Wed, 11 Dec 2019 18:34:26 +0000 Subject: [aarch64-port-dev ] [RFR] [8u] 8u242-b01 Upstream Sync In-Reply-To: <646b15f6-a7bc-b5c5-a502-83fb3df9f54d@redhat.com> References: <646b15f6-a7bc-b5c5-a502-83fb3df9f54d@redhat.com> Message-ID: <07045dd6-b463-6d27-fbe8-b960e1336f60@redhat.com> On 11/27/19 5:31 AM, Andrew John Hughes wrote: > Webrevs: https://cr.openjdk.java.net/~andrew/shenandoah-8/u242-b01/ > > Merge changesets: > > http://cr.openjdk.java.net/~andrew/shenandoah-8/u242-b01/corba/merge.changeset > http://cr.openjdk.java.net/~andrew/shenandoah-8/u242-b01/jaxp/merge.changeset > http://cr.openjdk.java.net/~andrew/shenandoah-8/u242-b01/jaxws/merge.changeset > http://cr.openjdk.java.net/~andrew/shenandoah-8/u242-b01/jdk/merge.changeset > http://cr.openjdk.java.net/~andrew/shenandoah-8/u242-b01/hotspot/merge.changeset > http://cr.openjdk.java.net/~andrew/shenandoah-8/u242-b01/langtools/merge.changeset > http://cr.openjdk.java.net/~andrew/shenandoah-8/u242-b01/nashorn/merge.changeset > http://cr.openjdk.java.net/~andrew/shenandoah-8/u242-b01/root/merge.changeset OK, thanks. -- Andrew Haley (he/him) Java Platform Lead Engineer Red Hat UK Ltd. https://keybase.io/andrewhaley EAC8 43EB D3EF DB98 CC77 2FAD A5CD 6035 332F A671 From aph at redhat.com Wed Dec 11 20:16:18 2019 From: aph at redhat.com (Andrew Haley) Date: Wed, 11 Dec 2019 20:16:18 +0000 Subject: [aarch64-port-dev ] RFR: 8234794: AArch64: runtime/memory/ReadFromNoaccessArea.java crashes In-Reply-To: References: Message-ID: <917ec3f4-f3a7-8f18-3f80-b1a1c0657318@redhat.com> On 12/11/19 7:08 AM, Nick Gasson wrote: > Bug: https://bugs.openjdk.java.net/browse/JDK-8234794 > Webrev: http://cr.openjdk.java.net/~ngasson/8234794/webrev.01/ Thanks. A few nits: This recalculates klass_decode_mode() a thousand times on only a small program. Be aware that C2 creates a new Assembler instance for most patterns. _klass_decode_mode could be calculated only once. Make it static and it will be. This inverted logic: #if !(defined(AARCH64) || defined(AIX)) return ReservedSpace(size, alignment, large_pages, requested_addr); #else // AARCH64 || AIX looks a bit cumbersome. It might be nice to do it the other way up, so that reserve_preferred_space is called from a static generic allocate method. Rather than explicitly defined(AARCH64) || defined(AIX) you might like to consider a named macro #if OS_CPU_USES_PREFERRED_SPACE return reserve_preferred_space( ... endif -- Andrew Haley (he/him) Java Platform Lead Engineer Red Hat UK Ltd. https://keybase.io/andrewhaley EAC8 43EB D3EF DB98 CC77 2FAD A5CD 6035 332F A671 From gnu.andrew at redhat.com Thu Dec 12 03:16:37 2019 From: gnu.andrew at redhat.com (Andrew John Hughes) Date: Thu, 12 Dec 2019 03:16:37 +0000 Subject: [aarch64-port-dev ] RFR: Bulk integration from shenandoah/jdk8 In-Reply-To: References: Message-ID: On 09/12/2019 14:33, Roman Kennke wrote: > Hello all, > > I'd like to propose integration of outstanding changes and backports > from shenandoah/jdk8. > > This time it is rather big. Most significantly, it includes LRB, > elimination of forwarding pointer, the new x86_32 port, the Traversal > GC, plus a whole lot of related bugfixes. > > The list of changes: > http://cr.openjdk.java.net/~rkennke/aarch64-shenandoah-integration-2019-12-09/changesets.txt > > Shared-only webrev: > http://cr.openjdk.java.net/~rkennke/aarch64-shenandoah-integration-2019-12-09/webrev-shared-only.00/ > > Full webrev: > http://cr.openjdk.java.net/~rkennke/aarch64-shenandoah-integration-2019-12-09/webrev-all.00/ > > There are quite many shared-code changes involved in this. However, most > of them actually revert/remove existing shared-code changes vs upstream > jdk8u, so the net effect is a drastic improvement. We added a few new > hooks (for the LRB), but we kept it inside the following pattern > wherever possible: > > #ifdef INCLUDE_ALL_GCS > if (UseShenandoahGC) {... > } > #endif > > Also, this change includes some renaming and moving-around of > (Shenandoah) files to keep Shenandoah code in Shenandoah subdirectories, > and follow the naming scheme of >=11 as much as possible. > > Can I please get a review of this? > > Thanks, > Roman > I looked over the shared webrev and it looks ok to me. I got the same impression of it mainly being a cleanup exercise before I saw your comment in the same vein, and it should make merges with 8u easier. We should get this in ASAP as it's already get late in the cycle for the January release. Thanks, -- Andrew :) Senior Free Java Software Engineer Red Hat, Inc. (http://www.redhat.com) PGP Key: ed25519/0xCFDA0F9B35964222 (hkp://keys.gnupg.net) Fingerprint = 5132 579D D154 0ED2 3E04 C5A0 CFDA 0F9B 3596 4222 https://keybase.io/gnu_andrew From nick.gasson at arm.com Thu Dec 12 08:31:12 2019 From: nick.gasson at arm.com (Nick Gasson) Date: Thu, 12 Dec 2019 16:31:12 +0800 Subject: [aarch64-port-dev ] RFR: 8234794: AArch64: runtime/memory/ReadFromNoaccessArea.java crashes In-Reply-To: <917ec3f4-f3a7-8f18-3f80-b1a1c0657318@redhat.com> References: <917ec3f4-f3a7-8f18-3f80-b1a1c0657318@redhat.com> Message-ID: On 12/12/2019 04:16, Andrew Haley wrote: > On 12/11/19 7:08 AM, Nick Gasson wrote: >> Bug: https://bugs.openjdk.java.net/browse/JDK-8234794 >> Webrev: http://cr.openjdk.java.net/~ngasson/8234794/webrev.01/ > > Thanks. A few nits: Please see the updated webrev: http://cr.openjdk.java.net/~ngasson/8234794/webrev.02/ > > This recalculates klass_decode_mode() a thousand times on only a small > program. Be aware that C2 creates a new Assembler instance for most patterns. > > _klass_decode_mode could be calculated only once. Make it static and it > will be. Yes. Also added an assert that Metaspace::initialized() in case we call it too early. > > This inverted logic: > > #if !(defined(AARCH64) || defined(AIX)) > return ReservedSpace(size, alignment, large_pages, requested_addr); > #else // AARCH64 || AIX > > looks a bit cumbersome. It might be nice to do it the other way up, so > that reserve_preferred_space is called from a static generic allocate > method. > > Rather than explicitly defined(AARCH64) || defined(AIX) you might like to > consider a named macro > > #if OS_CPU_USES_PREFERRED_SPACE > return reserve_preferred_space( ... > endif > OK. Metaspace::reserve_preferred_space() is now only defined if PREFERRED_METASPACE_ALIGNMENT is set. The generic method is Metaspace::reserve_space(). MetaspaceShared::reserve_shared_space() is now just a trivial wrapper for this so maybe it can be removed. I put the definition in the CPU's globalDefinitions.hpp because we don't have one for os_cpu, and we need it for every AArch64 system anyway. Also fixed the break/return inconsistency suggested by Jiangli. Thanks, Nick From ci_notify at linaro.org Thu Dec 12 09:29:55 2019 From: ci_notify at linaro.org (ci_notify at linaro.org) Date: Thu, 12 Dec 2019 09:29:55 +0000 (UTC) Subject: [aarch64-port-dev ] JTREG, JCStress, SPECjbb2015 and Hadoop/Terasort results for OpenJDK JDK on AArch64 Message-ID: <1245606120.4400.1576142996353.JavaMail.javamailuser@localhost> This is a summary of the JTREG test results =========================================== The build and test results are cycled every 15 days. For detailed information on the test output please refer to: http://openjdk.linaro.org/jdkX/openjdk-jtreg-nightly-tests/summary/2019/345/summary.html ------------------------------------------------------------------------------- client-release/hotspot ------------------------------------------------------------------------------- Build 0: aarch64/2018/oct/15 pass: 5,780; fail: 19; not run: 90 ------------------------------------------------------------------------------- client-release/jdk ------------------------------------------------------------------------------- Build 0: aarch64/2018/oct/15 pass: 8,495; fail: 670; error: 23 ------------------------------------------------------------------------------- client-release/langtools ------------------------------------------------------------------------------- Build 0: aarch64/2018/oct/15 pass: 3,970; fail: 5 ------------------------------------------------------------------------------- release/hotspot ------------------------------------------------------------------------------- Build 0: aarch64/2019/nov/08 pass: 5,761 Build 1: aarch64/2019/nov/11 pass: 5,762 Build 2: aarch64/2019/nov/13 pass: 5,764; fail: 1 Build 3: aarch64/2019/nov/15 pass: 5,750 Build 4: aarch64/2019/nov/18 pass: 5,750; fail: 1 Build 5: aarch64/2019/nov/20 pass: 5,752 Build 6: aarch64/2019/nov/22 pass: 5,752; fail: 1 Build 7: aarch64/2019/nov/25 pass: 5,752; fail: 1 Build 8: aarch64/2019/nov/27 pass: 5,752; fail: 2 Build 9: aarch64/2019/nov/29 pass: 5,752; fail: 2 Build 10: aarch64/2019/dec/02 pass: 5,753; fail: 4 Build 11: aarch64/2019/dec/04 pass: 5,755; fail: 2 Build 12: aarch64/2019/dec/07 pass: 5,762; fail: 1 Build 13: aarch64/2019/dec/09 pass: 5,762; fail: 1 Build 14: aarch64/2019/dec/11 pass: 5,765; fail: 44 ------------------------------------------------------------------------------- release/jdk ------------------------------------------------------------------------------- Build 0: aarch64/2019/nov/08 pass: 8,774; fail: 510; error: 17 Build 1: aarch64/2019/nov/11 pass: 8,777; fail: 509; error: 15 Build 2: aarch64/2019/nov/13 pass: 8,773; fail: 509; error: 21 Build 3: aarch64/2019/nov/15 pass: 8,756; fail: 511; error: 19 Build 4: aarch64/2019/nov/18 pass: 8,765; fail: 504; error: 18 Build 5: aarch64/2019/nov/20 pass: 8,768; fail: 504; error: 19 Build 6: aarch64/2019/nov/22 pass: 8,769; fail: 507; error: 18 Build 7: aarch64/2019/nov/25 pass: 8,775; fail: 509; error: 17 Build 8: aarch64/2019/nov/27 pass: 8,779; fail: 506; error: 22 Build 9: aarch64/2019/nov/29 pass: 8,784; fail: 503; error: 20 Build 10: aarch64/2019/dec/02 pass: 8,784; fail: 507; error: 19 Build 11: aarch64/2019/dec/04 pass: 8,788; fail: 505; error: 17 Build 12: aarch64/2019/dec/07 pass: 8,819; fail: 524; error: 17 Build 13: aarch64/2019/dec/09 pass: 8,820; fail: 519; error: 21 Build 14: aarch64/2019/dec/11 pass: 8,818; fail: 520; error: 18 3 fatal errors were detected; please follow the link above for more detail. ------------------------------------------------------------------------------- release/langtools ------------------------------------------------------------------------------- Build 0: aarch64/2019/nov/08 pass: 3,980 Build 1: aarch64/2019/nov/11 pass: 3,980 Build 2: aarch64/2019/nov/13 pass: 3,980 Build 3: aarch64/2019/nov/15 pass: 3,981 Build 4: aarch64/2019/nov/18 pass: 3,981 Build 5: aarch64/2019/nov/20 pass: 3,981 Build 6: aarch64/2019/nov/22 pass: 3,981 Build 7: aarch64/2019/nov/25 pass: 3,983 Build 8: aarch64/2019/nov/27 pass: 4,006 Build 9: aarch64/2019/nov/29 pass: 4,006 Build 10: aarch64/2019/dec/02 pass: 4,002; fail: 5; error: 1 Build 11: aarch64/2019/dec/04 pass: 4,008 Build 12: aarch64/2019/dec/07 pass: 4,019 Build 13: aarch64/2019/dec/09 pass: 4,019 Build 14: aarch64/2019/dec/11 pass: 4,021 ------------------------------------------------------------------------------- server-release/hotspot ------------------------------------------------------------------------------- Build 0: aarch64/2018/oct/15 pass: 5,787; fail: 18; not run: 90 ------------------------------------------------------------------------------- server-release/jdk ------------------------------------------------------------------------------- Build 0: aarch64/2018/oct/15 pass: 8,476; fail: 686; error: 27 ------------------------------------------------------------------------------- server-release/langtools ------------------------------------------------------------------------------- Build 0: aarch64/2018/oct/15 pass: 3,970; fail: 5 Previous results can be found here: http://openjdk.linaro.org/jdkX/openjdk-jtreg-nightly-tests/index.html SPECjbb2015 composite regression test completed =============================================== This test measures the relative performance of the server compiler running the SPECjbb2015 composite tests and compares the performance against the baseline performance of the server compiler taken on 2016-11-21. In accordance with [1], the SPECjbb2015 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): 7.92x Relative performance: Server critical-jOPS (nc): 9.90x Details of the test setup and historical results may be found here: http://openjdk.linaro.org/jdkX/SPECjbb2015-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 server compiler on 2014-04-01. Relative performance: Zero: 1.0, Server: 210.67 Server 210.67 / Server 2014-04-01 (71.00): 2.97x Details of the test setup and historical results may be found here: http://openjdk.linaro.org/jdkX/hadoop-terasort-benchmark-results/ This is a summary of the jcstress test results ============================================== The build and test results are cycled every 15 days. 2019-11-07 pass rate: 10490/10490, results: http://openjdk.linaro.org/jdkX/jcstress-nightly-runs/2019/310/results/ 2019-11-12 pass rate: 10490/10490, results: http://openjdk.linaro.org/jdkX/jcstress-nightly-runs/2019/315/results/ 2019-11-14 pass rate: 10490/10490, results: http://openjdk.linaro.org/jdkX/jcstress-nightly-runs/2019/317/results/ 2019-11-16 pass rate: 10490/10490, results: http://openjdk.linaro.org/jdkX/jcstress-nightly-runs/2019/319/results/ 2019-11-19 pass rate: 10490/10490, results: http://openjdk.linaro.org/jdkX/jcstress-nightly-runs/2019/322/results/ 2019-11-21 pass rate: 10490/10490, results: http://openjdk.linaro.org/jdkX/jcstress-nightly-runs/2019/324/results/ 2019-11-23 pass rate: 10490/10490, results: http://openjdk.linaro.org/jdkX/jcstress-nightly-runs/2019/326/results/ 2019-11-26 pass rate: 10490/10490, results: http://openjdk.linaro.org/jdkX/jcstress-nightly-runs/2019/329/results/ 2019-12-03 pass rate: 10490/10490, results: http://openjdk.linaro.org/jdkX/jcstress-nightly-runs/2019/331/results/ 2019-12-04 pass rate: 10490/10490, results: http://openjdk.linaro.org/jdkX/jcstress-nightly-runs/2019/333/results/ 2019-12-05 pass rate: 10490/10490, results: http://openjdk.linaro.org/jdkX/jcstress-nightly-runs/2019/336/results/ 2019-12-07 pass rate: 10490/10490, results: http://openjdk.linaro.org/jdkX/jcstress-nightly-runs/2019/338/results/ 2019-12-08 pass rate: 10490/10490, results: http://openjdk.linaro.org/jdkX/jcstress-nightly-runs/2019/341/results/ 2019-12-10 pass rate: 10490/10490, results: http://openjdk.linaro.org/jdkX/jcstress-nightly-runs/2019/343/results/ 2019-12-12 pass rate: 10490/10490, results: http://openjdk.linaro.org/jdkX/jcstress-nightly-runs/2019/345/results/ For detailed information on the test output please refer to: http://openjdk.linaro.org/jdkX/jcstress-nightly-runs/ From martin.doerr at sap.com Thu Dec 12 09:36:51 2019 From: martin.doerr at sap.com (Doerr, Martin) Date: Thu, 12 Dec 2019 09:36:51 +0000 Subject: [aarch64-port-dev ] does C1+CMS miss a storestore membar in jdk8u-shenandoah? In-Reply-To: References: Message-ID: Hi lx, seems like the following issue should get backported: https://bugs.openjdk.java.net/browse/JDK-8135018 Btw. I believe PPC is fine because C1 is not supported in 8u (at least not in the official repo). Best regards, Martin > -----Original Message----- > From: jdk8u-dev On Behalf Of Liu > Xin > Sent: Donnerstag, 12. Dezember 2019 08:40 > To: aarch64-port-dev at openjdk.java.net; ppc-aix-port- > dev at openjdk.java.net; jdk8u-dev at openjdk.java.net > Subject: does C1+CMS miss a storestore membar in jdk8u-shenandoah? > > Hi, Aarch64 & PowerPC community, > > I think this is only for arm and ppc because only they are use relaxed > memory ordering. x86 and sparc use TSO so storestore membar doesn't > matter > for them. please correct me if I am wrong. > > I feel that C1's > LIRGenerator::CardTableModRef_post_barrier(c1_LIRGenerator.cpp) misses > a > storestore membar for CMS on jdk8u. Could you review my observation? If I > am right, I'd like to file a bug and fix it. > > One reference is oop.inline.hpp. CMS uses the following function: > template inline void oop_store(volatile T* p, oop v) > It will emit a write_mem_barrier before cardTable updates. > > Another reference is C2 code. GraphKit::write_barrier_post generates > storeCM for CMS. > // Smash zero into card > if( !UseConcMarkSweepGC ) { > __ store(__ ctrl(), card_adr, zero, bt, adr_type, MemNode::release); > } else { > // Specialized path for CM store barrier > __ storeCM(__ ctrl(), card_adr, zero, oop_store, adr_idx, bt, adr_type); > } > > Actually, it's not only C1 has this bug. Template interpreter has this > problem too. It only happens for aarch64. do_oop_store in > templateTable_aarch64.cpp doesn't have any membar for CMS. By contrast, > ppc64 does have a membar(StoreStore). > > (macroAssembly_ppc.cpp) > > // Write the card table byte. > void MacroAssembler::card_table_write(jbyte* byte_map_base, Register > Rtmp, > Register Robj) { > assert_different_registers(Robj, Rtmp, R0); > load_const_optimized(Rtmp, (address)byte_map_base, R0); > srdi(Robj, Robj, CardTableModRefBS::card_shift); > li(R0, 0); // dirty > if (UseConcMarkSweepGC) membar(Assembler::StoreStore); > stbx(R0, Rtmp, Robj); > } > > I also check the jdk11 and jdk14, c1 and template interpreter both > consider concurrent_scanning case. please check out the following > functions. so only jdk8u is at risk. > CardTableBarrierSetC1::post_barrier > CardTableBarrierSetAssembler::store_check > > thanks, > --lx From aph at redhat.com Thu Dec 12 10:18:38 2019 From: aph at redhat.com (Andrew Haley) Date: Thu, 12 Dec 2019 10:18:38 +0000 Subject: [aarch64-port-dev ] does C1+CMS miss a storestore membar in jdk8u-shenandoah? In-Reply-To: References: Message-ID: <2b433414-fab1-c63d-1e07-76ddd4abe298@redhat.com> On 12/12/19 9:36 AM, Doerr, Martin wrote: > seems like the following issue should get backported: > https://bugs.openjdk.java.net/browse/JDK-8135018 > > Btw. I believe PPC is fine because C1 is not supported in 8u (at least not in the official repo). Oh yes, that's one of mine. We should backport it. -- Andrew Haley (he/him) Java Platform Lead Engineer Red Hat UK Ltd. https://keybase.io/andrewhaley EAC8 43EB D3EF DB98 CC77 2FAD A5CD 6035 332F A671 From jianglizhou at google.com Wed Dec 11 16:39:40 2019 From: jianglizhou at google.com (Jiangli Zhou) Date: Wed, 11 Dec 2019 08:39:40 -0800 Subject: [aarch64-port-dev ] RFR: 8234794: AArch64: runtime/memory/ReadFromNoaccessArea.java crashes In-Reply-To: References: Message-ID: Hi Nick, Looks good to me (although it's been years since I worked on any ARM ports). The detailed background and explanation are very nice! One nit for consistency. The 'KlassDecodeMovk' case returns, while the rest of the cases in MacroAssembler::encode_klass_not_null use break. 3963 return; Best regards, Jiangli On Tue, Dec 10, 2019 at 11:09 PM Nick Gasson wrote: > > Hi, > > Please help to review this patch to fix some issues uncovered by CDS > archive relocation. > > Bug: https://bugs.openjdk.java.net/browse/JDK-8234794 > Webrev: http://cr.openjdk.java.net/~ngasson/8234794/webrev.01/ > > As a bit of background, on AArch64 there are a few different ways we can > decode/encode compressed klass pointers, depending on the base address > alignment and shift. > > (1) If the base is NULL then it's a no-op or shift. > > (2) If we can encode the the base as a logical immediate, use an EOR > instruction to encode/decode. > > (3) If the base is 4G aligned and the shift is zero, use a MOVK > instruction to combine the base and offset. > > (4) Otherwise emit an inefficient sequence using rheapbase as a > temporary, and then restore the heap base (poorly tested). > > On AArch64 and AIX we have a loop in > Metaspace::allocate_metaspace_compressed_klass_ptrs that searches for a > 4G aligned location to map the compressed class space and enable > optimisations (2) and (3) above. It's possible to fail and fall through > to (4) after mmap-ing at an arbitrary address, but I think in practice > this never happens. > > MetaspaceShared allocates the compressed class space in a different way, > but the default base address is 0x80000000 which allows method (2) > above. After the changes in 8231610 the CDS archive can be relocated to > an arbitrary location decided by mmap, which makes case (4) much more > likely. > > The test case in the title passes -XX:HeapBaseMinAddress=33g which > triggers the CDS relocation. The combination of (4) and the extra > shift/add from the non-NULL narrow OOP base overflows the itable stub > code buffer. > > I want to fix this by ensuring that the compressed klass space is always > at least 4G aligned on AArch64 so we can get rid of (4). This will > reduce the variability in code size from memory layout, reduce the > number of configurations we need to test, and makes repurposing > rheapbase easier (see the review thread for 8233743). > > This patch moves the AArch64/AIX address space search loop into a new > function Metaspace::reserve_preferred_space. > MetaspaceShared::reserve_shared_space now calls this rather than > directly constructing the ReservedSpace. If use_requested_addr is false > it will search for a suitably aligned location (replacement for > ReservedSpace() with requested_addr=NULL), otherwise it checks the fixed > address meets the alignment requirements. Should be no functional change > on platforms other than AArch64 and AIX. > > Additionally, to support method (3) when the compressed klass shift is > non-zero (which it always is when CDS is on), the compressed klass base > will be aligned to a (4 << LogKlassAlignmentInBytes)*G boundary when the > base is above 32GB (limit for zero-based address). This allows us to > shift the base address right LogKlassAlignmentInBytes bits and use MOVK > to add it to the offset (discarding the lower 32 bits). I added an extra > case to SharedBaseAddress.java to cover this during jtreg testing. > > Finally there's a small bug in the existing code to determine if we can > use the EOR optimisation (2). > > use_XOR_for_compressed_class_base > = operand_valid_for_logical_immediate > (/*is32*/false, (uint64_t)CompressedKlassPointers::base()) > && ((uint64_t)CompressedKlassPointers::base() > > (1UL << log2_intptr(CompressedKlassPointers::range()))); > > This doesn't work if e.g. the base is 0x180000000 and the rounded-up > range is 0x100000000 because the high significant bits of the compressed > pointer overlap with the low significant bits of the base, even though > the base is strictly greater than the range. So the following will SEGV > with the current VM: > > java -Xmx128m -XX:SharedBaseAddress=6g -Xshare:dump > > Fixed this and moved all the logic for deciding which scheme to use into > MacroAssembler::klass_decode_mode. > > Tested jtreg hotspot_all_no_apps, jdk_core on AArch64 and x86. Also did > some manual testing with -XX:SharedBaseAddress and > -XX:ArchiveRelocationMode=1 (thanks Ioi). > > I'm not able to test on AIX which shares the same metaspace code (CC'd > ppc-aix-port-dev). > > > Thanks, > Nick > > From navy.xliu at gmail.com Thu Dec 12 07:40:04 2019 From: navy.xliu at gmail.com (Liu Xin) Date: Wed, 11 Dec 2019 23:40:04 -0800 Subject: [aarch64-port-dev ] does C1+CMS miss a storestore membar in jdk8u-shenandoah? Message-ID: Hi, Aarch64 & PowerPC community, I think this is only for arm and ppc because only they are use relaxed memory ordering. x86 and sparc use TSO so storestore membar doesn't matter for them. please correct me if I am wrong. I feel that C1's LIRGenerator::CardTableModRef_post_barrier(c1_LIRGenerator.cpp) misses a storestore membar for CMS on jdk8u. Could you review my observation? If I am right, I'd like to file a bug and fix it. One reference is oop.inline.hpp. CMS uses the following function: template inline void oop_store(volatile T* p, oop v) It will emit a write_mem_barrier before cardTable updates. Another reference is C2 code. GraphKit::write_barrier_post generates storeCM for CMS. // Smash zero into card if( !UseConcMarkSweepGC ) { __ store(__ ctrl(), card_adr, zero, bt, adr_type, MemNode::release); } else { // Specialized path for CM store barrier __ storeCM(__ ctrl(), card_adr, zero, oop_store, adr_idx, bt, adr_type); } Actually, it's not only C1 has this bug. Template interpreter has this problem too. It only happens for aarch64. do_oop_store in templateTable_aarch64.cpp doesn't have any membar for CMS. By contrast, ppc64 does have a membar(StoreStore). (macroAssembly_ppc.cpp) // Write the card table byte. void MacroAssembler::card_table_write(jbyte* byte_map_base, Register Rtmp, Register Robj) { assert_different_registers(Robj, Rtmp, R0); load_const_optimized(Rtmp, (address)byte_map_base, R0); srdi(Robj, Robj, CardTableModRefBS::card_shift); li(R0, 0); // dirty if (UseConcMarkSweepGC) membar(Assembler::StoreStore); stbx(R0, Rtmp, Robj); } I also check the jdk11 and jdk14, c1 and template interpreter both consider concurrent_scanning case. please check out the following functions. so only jdk8u is at risk. CardTableBarrierSetC1::post_barrier CardTableBarrierSetAssembler::store_check thanks, --lx From rkennke at redhat.com Thu Dec 12 12:18:18 2019 From: rkennke at redhat.com (rkennke at redhat.com) Date: Thu, 12 Dec 2019 12:18:18 +0000 Subject: [aarch64-port-dev ] hg: aarch64-port/jdk8u-shenandoah/hotspot: 73 new changesets Message-ID: <201912121218.xBCCIJNg001808@aojmv0008.oracle.com> Changeset: 880427372d04 Author: rkennke Date: 2019-10-23 13:07 +0200 URL: https://hg.openjdk.java.net/aarch64-port/jdk8u-shenandoah/hotspot/rev/880427372d04 Do not enable UseCountedLoopSafepoints in Shenandoah by default ! src/share/vm/runtime/arguments.cpp Changeset: 681483979efc Author: rkennke Date: 2019-10-21 11:17 +0200 URL: https://hg.openjdk.java.net/aarch64-port/jdk8u-shenandoah/hotspot/rev/681483979efc [backport] 8221766: Load-reference barriers for Shenandoah ! make/excludeSrc.make ! src/cpu/aarch64/vm/aarch64.ad ! src/cpu/aarch64/vm/c1_LIRAssembler_aarch64.cpp ! src/cpu/aarch64/vm/c1_LIRGenerator_aarch64.cpp ! src/cpu/aarch64/vm/interp_masm_aarch64.cpp ! src/cpu/aarch64/vm/jniFastGetField_aarch64.cpp ! src/cpu/aarch64/vm/macroAssembler_aarch64.cpp ! src/cpu/aarch64/vm/macroAssembler_aarch64.hpp ! src/cpu/aarch64/vm/methodHandles_aarch64.cpp ! src/cpu/aarch64/vm/sharedRuntime_aarch64.cpp + src/cpu/aarch64/vm/shenandoahBarrierSetAssembler_aarch64.cpp + src/cpu/aarch64/vm/shenandoahBarrierSetAssembler_aarch64.hpp - src/cpu/aarch64/vm/shenandoahBarrierSet_aarch64.cpp ! src/cpu/aarch64/vm/stubGenerator_aarch64.cpp ! src/cpu/aarch64/vm/stubRoutines_aarch64.cpp ! src/cpu/aarch64/vm/stubRoutines_aarch64.hpp ! src/cpu/aarch64/vm/templateInterpreter_aarch64.cpp ! src/cpu/aarch64/vm/templateTable_aarch64.cpp ! src/cpu/x86/vm/c1_LIRAssembler_x86.cpp ! src/cpu/x86/vm/c1_LIRGenerator_x86.cpp ! src/cpu/x86/vm/interp_masm_x86_64.cpp ! src/cpu/x86/vm/jniFastGetField_x86_64.cpp ! src/cpu/x86/vm/macroAssembler_x86.cpp ! src/cpu/x86/vm/macroAssembler_x86.hpp ! src/cpu/x86/vm/methodHandles_x86.cpp ! src/cpu/x86/vm/sharedRuntime_x86_64.cpp + src/cpu/x86/vm/shenandoahBarrierSetAssembler_x86.cpp + src/cpu/x86/vm/shenandoahBarrierSetAssembler_x86.hpp - src/cpu/x86/vm/shenandoahBarrierSet_x86.cpp ! src/cpu/x86/vm/stubGenerator_x86_64.cpp ! src/cpu/x86/vm/stubRoutines_x86_64.cpp ! src/cpu/x86/vm/stubRoutines_x86_64.hpp ! src/cpu/x86/vm/templateInterpreter_x86_64.cpp ! src/cpu/x86/vm/templateTable_x86_64.cpp ! src/cpu/x86/vm/x86_64.ad ! src/share/vm/c1/c1_LIR.cpp ! src/share/vm/c1/c1_LIR.hpp ! src/share/vm/c1/c1_LIRAssembler.hpp ! src/share/vm/c1/c1_LIRGenerator.cpp ! src/share/vm/c1/c1_LIRGenerator.hpp ! src/share/vm/c1/c1_Runtime1.cpp ! src/share/vm/ci/ciEnv.cpp ! src/share/vm/ci/ciObjectFactory.cpp ! src/share/vm/ci/ciObjectFactory.hpp ! src/share/vm/classfile/classLoaderData.cpp ! src/share/vm/classfile/classLoaderStats.hpp ! src/share/vm/classfile/dictionary.cpp ! src/share/vm/classfile/javaClasses.cpp ! src/share/vm/classfile/systemDictionary.cpp ! src/share/vm/code/dependencies.cpp ! src/share/vm/compiler/oopMap.hpp ! src/share/vm/gc_implementation/shenandoah/heuristics/shenandoahAdaptiveHeuristics.cpp ! src/share/vm/gc_implementation/shenandoah/heuristics/shenandoahAggressiveHeuristics.cpp ! src/share/vm/gc_implementation/shenandoah/heuristics/shenandoahCompactHeuristics.cpp ! src/share/vm/gc_implementation/shenandoah/heuristics/shenandoahPassiveHeuristics.cpp ! src/share/vm/gc_implementation/shenandoah/heuristics/shenandoahStaticHeuristics.cpp ! src/share/vm/gc_implementation/shenandoah/shenandoahAsserts.cpp ! src/share/vm/gc_implementation/shenandoah/shenandoahBarrierSet.cpp ! src/share/vm/gc_implementation/shenandoah/shenandoahBarrierSet.hpp + src/share/vm/gc_implementation/shenandoah/shenandoahBarrierSetC1.cpp + src/share/vm/gc_implementation/shenandoah/shenandoahBarrierSetC1.hpp + src/share/vm/gc_implementation/shenandoah/shenandoahBarrierSetC2.cpp + src/share/vm/gc_implementation/shenandoah/shenandoahBarrierSetC2.hpp ! src/share/vm/gc_implementation/shenandoah/shenandoahBrooksPointer.inline.hpp ! src/share/vm/gc_implementation/shenandoah/shenandoahClosures.inline.hpp ! src/share/vm/gc_implementation/shenandoah/shenandoahCodeRoots.cpp ! src/share/vm/gc_implementation/shenandoah/shenandoahConcurrentMark.inline.hpp ! src/share/vm/gc_implementation/shenandoah/shenandoahHeap.cpp ! src/share/vm/gc_implementation/shenandoah/shenandoahHeap.hpp ! src/share/vm/gc_implementation/shenandoah/shenandoahHeap.inline.hpp ! src/share/vm/gc_implementation/shenandoah/shenandoahRootProcessor.cpp ! src/share/vm/gc_implementation/shenandoah/shenandoahRootProcessor.hpp + src/share/vm/gc_implementation/shenandoah/shenandoahRuntime.cpp + src/share/vm/gc_implementation/shenandoah/shenandoahRuntime.hpp ! src/share/vm/gc_implementation/shenandoah/shenandoahStrDedupTable.cpp ! src/share/vm/gc_implementation/shenandoah/shenandoahStrDedupTable.hpp + src/share/vm/gc_implementation/shenandoah/shenandoahSupport.cpp + src/share/vm/gc_implementation/shenandoah/shenandoahSupport.hpp ! src/share/vm/gc_implementation/shenandoah/shenandoahTaskqueue.hpp ! src/share/vm/gc_implementation/shenandoah/shenandoahVerifier.cpp ! src/share/vm/gc_implementation/shenandoah/shenandoah_globals.hpp ! src/share/vm/gc_interface/collectedHeap.inline.hpp ! src/share/vm/interpreter/interpreterRuntime.cpp ! src/share/vm/memory/barrierSet.cpp ! src/share/vm/memory/barrierSet.hpp ! src/share/vm/memory/binaryTreeDictionary.hpp ! src/share/vm/memory/referenceProcessor.cpp ! src/share/vm/memory/referenceProcessor.hpp ! src/share/vm/memory/universe.cpp ! src/share/vm/oops/instanceKlass.cpp ! src/share/vm/oops/klassVtable.cpp ! src/share/vm/oops/objArrayKlass.cpp ! src/share/vm/oops/objArrayOop.hpp ! src/share/vm/oops/oop.hpp ! src/share/vm/oops/oop.inline.hpp ! src/share/vm/oops/typeArrayKlass.cpp ! src/share/vm/oops/typeArrayOop.hpp ! src/share/vm/opto/addnode.cpp ! src/share/vm/opto/callnode.cpp ! src/share/vm/opto/cfgnode.cpp ! src/share/vm/opto/classes.cpp ! src/share/vm/opto/classes.hpp ! src/share/vm/opto/compile.cpp ! src/share/vm/opto/compile.hpp ! src/share/vm/opto/escape.cpp ! src/share/vm/opto/graphKit.cpp ! src/share/vm/opto/graphKit.hpp ! src/share/vm/opto/lcm.cpp ! src/share/vm/opto/library_call.cpp ! src/share/vm/opto/loopPredicate.cpp ! src/share/vm/opto/loopTransform.cpp ! src/share/vm/opto/loopnode.cpp ! src/share/vm/opto/loopnode.hpp ! src/share/vm/opto/loopopts.cpp ! src/share/vm/opto/machnode.cpp ! src/share/vm/opto/macro.cpp ! src/share/vm/opto/matcher.cpp ! src/share/vm/opto/memnode.cpp ! src/share/vm/opto/mulnode.cpp ! src/share/vm/opto/multnode.cpp ! src/share/vm/opto/node.cpp ! src/share/vm/opto/parse.hpp ! src/share/vm/opto/parse2.cpp ! src/share/vm/opto/parse3.cpp ! src/share/vm/opto/phaseX.cpp - src/share/vm/opto/shenandoahSupport.cpp - src/share/vm/opto/shenandoahSupport.hpp ! src/share/vm/opto/split_if.cpp ! src/share/vm/opto/stringopts.cpp ! src/share/vm/opto/subnode.cpp ! src/share/vm/prims/jni.cpp ! src/share/vm/prims/jvm.cpp ! src/share/vm/prims/jvmtiTagMap.cpp ! src/share/vm/prims/methodHandles.cpp ! src/share/vm/prims/unsafe.cpp ! src/share/vm/runtime/arguments.cpp ! src/share/vm/runtime/biasedLocking.cpp ! src/share/vm/runtime/handles.hpp ! src/share/vm/runtime/jniHandles.cpp ! src/share/vm/runtime/jniHandles.hpp ! src/share/vm/runtime/objectMonitor.hpp ! src/share/vm/runtime/reflection.cpp ! src/share/vm/runtime/synchronizer.cpp ! src/share/vm/runtime/thread.cpp ! src/share/vm/runtime/vframe.cpp ! src/share/vm/runtime/vmStructs.cpp ! src/share/vm/services/memoryManager.hpp ! src/share/vm/services/memoryPool.hpp ! src/share/vm/services/serviceUtil.hpp ! src/share/vm/services/threadService.cpp ! src/share/vm/utilities/growableArray.hpp ! test/gc/shenandoah/options/TestSelectiveBarrierFlags.java ! test/gc/shenandoah/options/TestWrongBarrierDisable.java Changeset: 96a982067b9f Author: rkennke Date: 2019-04-08 18:42 +0200 URL: https://hg.openjdk.java.net/aarch64-port/jdk8u-shenandoah/hotspot/rev/96a982067b9f [backport] 8222129: Shenandoah: Missing CompareAndSwapP/N case in get_barrier_strength() Reviewed-by: shade ! src/share/vm/gc_implementation/shenandoah/shenandoahSupport.cpp Changeset: a8ae1b2a6b99 Author: shade Date: 2019-05-07 16:04 +0200 URL: https://hg.openjdk.java.net/aarch64-port/jdk8u-shenandoah/hotspot/rev/a8ae1b2a6b99 [backport] 8223448: Shenandoah disabled barriers blocks omit LRB Reviewed-by: rkennke ! src/share/vm/runtime/arguments.cpp Changeset: 8258467f66ee Author: rkennke Date: 2019-05-23 17:01 +0200 URL: https://hg.openjdk.java.net/aarch64-port/jdk8u-shenandoah/hotspot/rev/8258467f66ee [backport] 8224667: Shenandoah: Post-LRB cleanup Reviewed-by: shade ! src/share/vm/gc_implementation/shenandoah/shenandoahBarrierSetC2.cpp ! src/share/vm/gc_implementation/shenandoah/shenandoahBarrierSetC2.hpp ! src/share/vm/gc_implementation/shenandoah/shenandoahSupport.cpp Changeset: 077b642d9aa9 Author: roland Date: 2019-07-29 13:22 +0200 URL: https://hg.openjdk.java.net/aarch64-port/jdk8u-shenandoah/hotspot/rev/077b642d9aa9 [backport] LRB right after call, use is Bool ! src/share/vm/gc_implementation/shenandoah/shenandoahSupport.cpp Changeset: 67b133abf376 Author: rkennke Date: 2019-07-31 10:03 +0200 URL: https://hg.openjdk.java.net/aarch64-port/jdk8u-shenandoah/hotspot/rev/67b133abf376 [backport] 8228775: Shenandoah: Remove useless null-input-verification in Shenandoah/C2 verifier Reviewed-by: shade ! src/share/vm/gc_implementation/shenandoah/shenandoahSupport.cpp Changeset: c74df59bb0f5 Author: rkennke Date: 2019-07-31 12:35 +0200 URL: https://hg.openjdk.java.net/aarch64-port/jdk8u-shenandoah/hotspot/rev/c74df59bb0f5 [backport] Relax Shenandoah/C2 verifier against JDK11 shortcomings ! src/share/vm/gc_implementation/shenandoah/shenandoahSupport.cpp Changeset: 0947da41a3fe Author: rkennke Date: 2019-08-02 11:21 +0200 URL: https://hg.openjdk.java.net/aarch64-port/jdk8u-shenandoah/hotspot/rev/0947da41a3fe [backport] 8229002: Shenandoah: Missing node types in ShenandoahLoadReferenceBarrier::needs_barrier_impl() Reviewed-by: shade ! src/share/vm/gc_implementation/shenandoah/shenandoahSupport.cpp Changeset: d72c41adb513 Author: roland Date: 2019-05-02 20:47 +0200 URL: https://hg.openjdk.java.net/aarch64-port/jdk8u-shenandoah/hotspot/rev/d72c41adb513 [backport] 8222738: Shenandoah: assert(is_Proj()) failed when running cometd benchmarks Reviewed-by: rkennke ! src/share/vm/gc_implementation/shenandoah/shenandoahSupport.cpp Changeset: 818d977d1b7c Author: shade Date: 2019-05-22 21:40 +0200 URL: https://hg.openjdk.java.net/aarch64-port/jdk8u-shenandoah/hotspot/rev/818d977d1b7c [backport] 8224522: Shenandoah should apply barriers on deoptimization Reviewed-by: rkennke, zgu ! src/share/vm/runtime/stackValue.cpp Changeset: 04fce1bceb31 Author: roland Date: 2019-05-22 10:11 +0200 URL: https://hg.openjdk.java.net/aarch64-port/jdk8u-shenandoah/hotspot/rev/04fce1bceb31 [backport] 8224496: Shenandoah compilation fails with assert(is_CountedLoopEnd()) failed: invalid node class Reviewed-by: rkennke ! src/share/vm/gc_implementation/shenandoah/shenandoahSupport.cpp Changeset: e1961573bf06 Author: shade Date: 2019-10-23 20:57 +0200 URL: https://hg.openjdk.java.net/aarch64-port/jdk8u-shenandoah/hotspot/rev/e1961573bf06 Fix Windows build after LRB backports ! src/share/vm/gc_implementation/shenandoah/shenandoahRuntime.cpp Changeset: b988f0d15442 Author: shade Date: 2019-10-23 21:15 +0200 URL: https://hg.openjdk.java.net/aarch64-port/jdk8u-shenandoah/hotspot/rev/b988f0d15442 Fix leftover commented out code in ShenandoahRuntime::load_reference_barrier_JRT ! src/share/vm/gc_implementation/shenandoah/shenandoahRuntime.cpp Changeset: 65c20f84209c Author: shade Date: 2019-10-24 10:35 +0200 URL: https://hg.openjdk.java.net/aarch64-port/jdk8u-shenandoah/hotspot/rev/65c20f84209c Revert ShenandoahVerifyObjectEquals additions, not required after LRB ! src/share/vm/oops/oopsHierarchy.hpp Changeset: 24f3a673bee4 Author: shade Date: 2019-10-24 12:56 +0200 URL: https://hg.openjdk.java.net/aarch64-port/jdk8u-shenandoah/hotspot/rev/24f3a673bee4 Remove StubRoutines::_shenandoah_wb_C and related code ! src/share/vm/opto/lcm.cpp ! src/share/vm/runtime/stubRoutines.cpp ! src/share/vm/runtime/stubRoutines.hpp Changeset: 704f605efe4c Author: shade Date: 2019-10-24 13:27 +0200 URL: https://hg.openjdk.java.net/aarch64-port/jdk8u-shenandoah/hotspot/rev/704f605efe4c Fix Zero build after LRB backport moves, remove other stubs ! make/linux/makefiles/vm.make - src/cpu/ppc/vm/shenandoahBarrierSet_ppc.cpp - src/cpu/sparc/vm/shenandoahBarrierSet_sparc.cpp - src/cpu/zero/vm/shenandoahBarrierSet_zero.cpp ! src/share/vm/gc_implementation/shenandoah/shenandoahBarrierSet.cpp + src/share/vm/gc_implementation/shenandoah/shenandoahBarrierSetAssembler_stub.hpp ! src/share/vm/utilities/macros.hpp Changeset: 5d8698318219 Author: shade Date: 2019-10-24 18:53 +0200 URL: https://hg.openjdk.java.net/aarch64-port/jdk8u-shenandoah/hotspot/rev/5d8698318219 Save vector registers before LRB slowpath call ! src/cpu/x86/vm/shenandoahBarrierSetAssembler_x86.cpp ! src/cpu/x86/vm/shenandoahBarrierSetAssembler_x86.hpp Changeset: dae45258de89 Author: shade Date: 2019-10-25 10:23 +0200 URL: https://hg.openjdk.java.net/aarch64-port/jdk8u-shenandoah/hotspot/rev/dae45258de89 Avoid initializing unused SharedHeap::_workers for Shenandoah ! src/share/vm/gc_implementation/shenandoah/shenandoahHeap.cpp ! src/share/vm/gc_implementation/shenandoah/shenandoahHeap.hpp ! src/share/vm/gc_implementation/shenandoah/shenandoahHeap.inline.hpp ! src/share/vm/memory/sharedHeap.cpp Changeset: e040b7d17b6f Author: roland Date: 2019-10-25 17:22 +0200 URL: https://hg.openjdk.java.net/aarch64-port/jdk8u-shenandoah/hotspot/rev/e040b7d17b6f Fix ShenandoahLoadReferenceBarrierNode::{Value, Identity} signatures after LRB backport ! src/share/vm/gc_implementation/shenandoah/shenandoahSupport.cpp ! src/share/vm/gc_implementation/shenandoah/shenandoahSupport.hpp Changeset: fabf567ee9dd Author: rkennke Date: 2019-10-28 14:33 +0100 URL: https://hg.openjdk.java.net/aarch64-port/jdk8u-shenandoah/hotspot/rev/fabf567ee9dd Correct order between load, LRB and membar nodes ! src/share/vm/opto/library_call.cpp Changeset: 66fab7238237 Author: rkennke Date: 2019-05-08 20:45 +0200 URL: https://hg.openjdk.java.net/aarch64-port/jdk8u-shenandoah/hotspot/rev/66fab7238237 [backport] 8223567: Rename ShenandoahBrooksPointer to ShenandoahForwarding Reviewed-by: shade ! src/cpu/aarch64/vm/shenandoahBarrierSetAssembler_aarch64.cpp ! src/cpu/x86/vm/shenandoahBarrierSetAssembler_x86.cpp ! src/cpu/x86/vm/x86_64.ad ! src/share/vm/asm/assembler.cpp ! src/share/vm/c1/c1_LIRGenerator.cpp ! src/share/vm/ci/ciInstanceKlass.cpp ! src/share/vm/gc_implementation/shenandoah/shenandoahAsserts.cpp ! src/share/vm/gc_implementation/shenandoah/shenandoahBarrierSet.cpp ! src/share/vm/gc_implementation/shenandoah/shenandoahBarrierSet.inline.hpp ! src/share/vm/gc_implementation/shenandoah/shenandoahBarrierSetC1.cpp - src/share/vm/gc_implementation/shenandoah/shenandoahBrooksPointer.hpp - src/share/vm/gc_implementation/shenandoah/shenandoahBrooksPointer.inline.hpp ! src/share/vm/gc_implementation/shenandoah/shenandoahConcurrentMark.cpp ! src/share/vm/gc_implementation/shenandoah/shenandoahConcurrentMark.inline.hpp + src/share/vm/gc_implementation/shenandoah/shenandoahForwarding.hpp + src/share/vm/gc_implementation/shenandoah/shenandoahForwarding.inline.hpp ! src/share/vm/gc_implementation/shenandoah/shenandoahHeap.cpp ! src/share/vm/gc_implementation/shenandoah/shenandoahHeap.inline.hpp ! src/share/vm/gc_implementation/shenandoah/shenandoahHeapRegion.cpp ! src/share/vm/gc_implementation/shenandoah/shenandoahHeuristics.cpp ! src/share/vm/gc_implementation/shenandoah/shenandoahMarkCompact.cpp ! src/share/vm/gc_implementation/shenandoah/shenandoahStringDedup.cpp ! src/share/vm/gc_implementation/shenandoah/shenandoahSupport.cpp ! src/share/vm/gc_implementation/shenandoah/shenandoahSupport.hpp ! src/share/vm/gc_implementation/shenandoah/shenandoahVerifier.cpp ! src/share/vm/opto/compile.cpp ! src/share/vm/opto/graphKit.cpp ! src/share/vm/opto/macro.cpp ! src/share/vm/opto/memnode.cpp ! src/share/vm/opto/type.cpp Changeset: fa0d7fae7231 Author: rkennke Date: 2019-05-29 12:01 +0200 URL: https://hg.openjdk.java.net/aarch64-port/jdk8u-shenandoah/hotspot/rev/fa0d7fae7231 [backport] 8224584: Shenandoah: Eliminate forwarding pointer word Reviewed-by: shade, roland ! src/cpu/aarch64/vm/macroAssembler_aarch64.cpp ! src/cpu/aarch64/vm/shenandoahBarrierSetAssembler_aarch64.cpp ! src/cpu/aarch64/vm/shenandoahBarrierSetAssembler_aarch64.hpp ! src/cpu/x86/vm/macroAssembler_x86.cpp ! src/cpu/x86/vm/shenandoahBarrierSetAssembler_x86.cpp ! src/cpu/x86/vm/shenandoahBarrierSetAssembler_x86.hpp ! src/cpu/x86/vm/templateTable_x86_64.cpp ! src/share/vm/asm/assembler.cpp ! src/share/vm/ci/ciInstanceKlass.cpp + src/share/vm/gc_implementation/shenandoah/preservedMarks.cpp + src/share/vm/gc_implementation/shenandoah/preservedMarks.hpp + src/share/vm/gc_implementation/shenandoah/preservedMarks.inline.hpp ! src/share/vm/gc_implementation/shenandoah/shenandoahAsserts.cpp ! src/share/vm/gc_implementation/shenandoah/shenandoahBarrierSet.cpp ! src/share/vm/gc_implementation/shenandoah/shenandoahConcurrentMark.inline.hpp ! src/share/vm/gc_implementation/shenandoah/shenandoahForwarding.hpp ! src/share/vm/gc_implementation/shenandoah/shenandoahForwarding.inline.hpp ! src/share/vm/gc_implementation/shenandoah/shenandoahHeap.cpp ! src/share/vm/gc_implementation/shenandoah/shenandoahHeap.hpp ! src/share/vm/gc_implementation/shenandoah/shenandoahHeap.inline.hpp ! src/share/vm/gc_implementation/shenandoah/shenandoahHeapRegion.cpp ! src/share/vm/gc_implementation/shenandoah/shenandoahHeuristics.cpp ! src/share/vm/gc_implementation/shenandoah/shenandoahMarkCompact.cpp ! src/share/vm/gc_implementation/shenandoah/shenandoahMarkCompact.hpp ! src/share/vm/gc_implementation/shenandoah/shenandoahSupport.cpp ! src/share/vm/gc_implementation/shenandoah/shenandoahVerifier.cpp ! src/share/vm/gc_interface/collectedHeap.cpp ! src/share/vm/gc_interface/collectedHeap.hpp ! src/share/vm/gc_interface/collectedHeap.inline.hpp ! src/share/vm/memory/threadLocalAllocBuffer.cpp ! src/share/vm/memory/threadLocalAllocBuffer.hpp ! src/share/vm/opto/macro.cpp ! src/share/vm/opto/memnode.cpp ! src/share/vm/opto/type.cpp ! src/share/vm/prims/jvmtiEnv.cpp ! src/share/vm/prims/jvmtiExport.cpp ! src/share/vm/prims/whitebox.cpp Changeset: 46d3abf81070 Author: shade Date: 2019-09-19 20:26 +0200 URL: https://hg.openjdk.java.net/aarch64-port/jdk8u-shenandoah/hotspot/rev/46d3abf81070 [backport] 8231197: Shenandoah: JVMTI heap walking cleanup crashes with NULL forwardee Reviewed-by: zgu, rkennke ! src/share/vm/gc_implementation/shenandoah/shenandoahCodeRoots.cpp ! src/share/vm/gc_implementation/shenandoah/shenandoahHeap.cpp Changeset: 24f427395b33 Author: shade Date: 2019-09-30 18:02 +0200 URL: https://hg.openjdk.java.net/aarch64-port/jdk8u-shenandoah/hotspot/rev/24f427395b33 [backport] 8231583: Shenandoah: Fix register clash in SBSA::resolve_forwarding_pointer() borrowing Reviewed-by: rkennke ! src/cpu/aarch64/vm/shenandoahBarrierSetAssembler_aarch64.cpp ! src/cpu/x86/vm/shenandoahBarrierSetAssembler_x86.cpp Changeset: 1b435382fd22 Author: shade Date: 2019-05-07 16:05 +0200 URL: https://hg.openjdk.java.net/aarch64-port/jdk8u-shenandoah/hotspot/rev/1b435382fd22 [backport] 8223450: Disable Shenandoah C2 barriers verification for x86_32 Reviewed-by: rkennke ! src/share/vm/runtime/arguments.cpp Changeset: 467cbba602cd Author: shade Date: 2019-06-13 19:37 +0200 URL: https://hg.openjdk.java.net/aarch64-port/jdk8u-shenandoah/hotspot/rev/467cbba602cd [backport] 8224881: Shenandoah: trashing "Collection Set, Pinned" region during Degenerated GC Reviewed-by: rkennke, zgu ! src/share/vm/gc_implementation/shenandoah/shenandoahHeap.cpp Changeset: 77927aa9dc51 Author: shade Date: 2019-10-07 17:12 +0200 URL: https://hg.openjdk.java.net/aarch64-port/jdk8u-shenandoah/hotspot/rev/77927aa9dc51 [backport] 8231946: Remove obsolete and unused ShenandoahVerifyObjectEquals flag Reviewed-by: rkennke ! src/share/vm/gc_implementation/shenandoah/shenandoah_globals.hpp Changeset: 7b0908dda120 Author: shade Date: 2019-06-05 09:23 +0200 URL: https://hg.openjdk.java.net/aarch64-port/jdk8u-shenandoah/hotspot/rev/7b0908dda120 [backport] 8225229: Shenandoah: trim down default number of GC threads Reviewed-by: rkennke ! src/share/vm/runtime/arguments.cpp + test/gc/shenandoah/options/TestThreadCounts.java Changeset: 824d54ea3705 Author: shade Date: 2019-10-07 17:12 +0200 URL: https://hg.openjdk.java.net/aarch64-port/jdk8u-shenandoah/hotspot/rev/824d54ea3705 [backport] 8231932: Shenandoah: conc/par GC threads ergonomics overrides user settings Reviewed-by: rkennke ! src/share/vm/runtime/arguments.cpp ! test/gc/shenandoah/TestGCThreadGroups.java ! test/gc/shenandoah/options/TestThreadCounts.java + test/gc/shenandoah/options/TestThreadCountsOverride.java Changeset: 6c1842b5aec5 Author: zgu Date: 2019-07-01 08:24 -0400 URL: https://hg.openjdk.java.net/aarch64-port/jdk8u-shenandoah/hotspot/rev/6c1842b5aec5 [backport] 8226957: Shenandoah: Remove obsoleted ShenandoahStoreCheck option Reviewed-by: shade ! src/share/vm/gc_implementation/shenandoah/shenandoah_globals.hpp ! test/gc/shenandoah/TestEvilSyncBug.java ! test/gc/shenandoah/TestVerifyJCStress.java Changeset: ab1c1efdbe85 Author: shade Date: 2019-10-21 15:11 +0200 URL: https://hg.openjdk.java.net/aarch64-port/jdk8u-shenandoah/hotspot/rev/ab1c1efdbe85 [backport] 8232702: Shenandoah: gc/shenandoah/TestVerifyJCStress.java uses non-existent -XX:+VerifyObjectEquals Reviewed-by: rkennke ! test/gc/shenandoah/TestVerifyJCStress.java Changeset: 4f0444442f8b Author: shade Date: 2019-05-30 10:21 +0200 URL: https://hg.openjdk.java.net/aarch64-port/jdk8u-shenandoah/hotspot/rev/4f0444442f8b [backport] 8225017: [TESTBUG] gc/shenandoah/oom/TestThreadFailure.java takes too long Reviewed-by: rkennke ! test/gc/shenandoah/oom/TestThreadFailure.java Changeset: 06c9bab61f02 Author: rkennke Date: 2019-10-29 13:45 +0100 URL: https://hg.openjdk.java.net/aarch64-port/jdk8u-shenandoah/hotspot/rev/06c9bab61f02 Use correct flag to guard implicit concurrent GC ! src/share/vm/gc_implementation/shenandoah/shenandoahControlThread.cpp Changeset: 379aec26322c Author: shade Date: 2019-06-02 10:08 +0200 URL: https://hg.openjdk.java.net/aarch64-port/jdk8u-shenandoah/hotspot/rev/379aec26322c [backport] 8225111: Make Shenandoah tests work with 32-bit VMs Reviewed-by: rkennke ! test/gc/shenandoah/TestHumongousThreshold.java ! test/gc/shenandoah/TestLargeObjectAlignment.java ! test/gc/shenandoah/compiler/TestNullCheck.java ! test/gc/shenandoah/compiler/TestReferenceCAS.java ! test/gc/shenandoah/jvmti/TestHeapDump.sh ! test/gc/shenandoah/options/TestObjectAlignment.java Changeset: bceb0f735e47 Author: shade Date: 2019-10-29 22:40 +0100 URL: https://hg.openjdk.java.net/aarch64-port/jdk8u-shenandoah/hotspot/rev/bceb0f735e47 Disable JNI tests for 32-bit platforms, due to lack of jtreg support ! test/gc/shenandoah/jni/TestCriticalNativeArgs.sh ! test/gc/shenandoah/jni/TestCriticalNativeStress.sh ! test/gc/shenandoah/jni/TestJNICritical.sh ! test/gc/shenandoah/jni/TestJNIGlobalRefs.sh ! test/gc/shenandoah/jni/TestPinnedGarbage.sh ! test/gc/shenandoah/jvmti/TestHeapDump.sh Changeset: 1542c6e7f936 Author: shade Date: 2019-06-02 10:08 +0200 URL: https://hg.openjdk.java.net/aarch64-port/jdk8u-shenandoah/hotspot/rev/1542c6e7f936 [backport] 8225048: Shenandoah x86_32 support Reviewed-by: erikj, rkennke ! src/cpu/x86/vm/shenandoahBarrierSetAssembler_x86.cpp ! src/cpu/x86/vm/stubGenerator_x86_32.cpp ! src/cpu/x86/vm/templateInterpreter_x86_32.cpp ! src/cpu/x86/vm/templateTable_x86_32.cpp ! src/cpu/x86/vm/x86_32.ad ! src/share/vm/gc_implementation/shenandoah/shenandoahSupport.cpp ! src/share/vm/runtime/arguments.cpp Changeset: d0912bb7bdfa Author: roland Date: 2019-09-26 17:49 +0200 URL: https://hg.openjdk.java.net/aarch64-port/jdk8u-shenandoah/hotspot/rev/d0912bb7bdfa [backport] 8231405: [Shenandoah] guarantee(d != NULL) failed: Null dominator info Reviewed-by: shade, rkennke ! src/share/vm/gc_implementation/shenandoah/shenandoahSupport.cpp + test/gc/shenandoah/compiler/CallMultipleCatchProjs.java Changeset: 3914b48481ac Author: shade Date: 2019-08-14 20:32 +0200 URL: https://hg.openjdk.java.net/aarch64-port/jdk8u-shenandoah/hotspot/rev/3914b48481ac [backport] 8229707: [TESTBUG] Some Shenandoah tests assume Server VM by default Reviewed-by: rkennke ! test/gc/shenandoah/compiler/TestWriteBarrierClearControl.java Changeset: f88ae7f24e3b Author: shade Date: 2019-08-09 13:07 +0200 URL: https://hg.openjdk.java.net/aarch64-port/jdk8u-shenandoah/hotspot/rev/f88ae7f24e3b [backport] 8229350: Shenandoah does not need barriers before CreateEx Reviewed-by: rkennke ! src/share/vm/gc_implementation/shenandoah/shenandoahSupport.cpp Changeset: f03386fe304d Author: shade Date: 2019-06-03 14:50 +0200 URL: https://hg.openjdk.java.net/aarch64-port/jdk8u-shenandoah/hotspot/rev/f03386fe304d [backport] 8225046: Shenandoah metrics logs refactoring Reviewed-by: rkennke ! src/share/vm/gc_implementation/shenandoah/shenandoahHeap.cpp ! src/share/vm/gc_implementation/shenandoah/shenandoahMetrics.cpp ! src/share/vm/gc_implementation/shenandoah/shenandoahMetrics.hpp Changeset: b0e521a0c3ec Author: shade Date: 2019-10-01 15:38 +0200 URL: https://hg.openjdk.java.net/aarch64-port/jdk8u-shenandoah/hotspot/rev/b0e521a0c3ec [backport] 8231667: Shenandoah: Full GC should take empty regions into slices for compaction Reviewed-by: rkennke ! src/share/vm/gc_implementation/shenandoah/shenandoahMarkCompact.cpp Changeset: cdda3f9e91c7 Author: zgu Date: 2019-05-29 09:43 -0400 URL: https://hg.openjdk.java.net/aarch64-port/jdk8u-shenandoah/hotspot/rev/cdda3f9e91c7 [backport] 8224932: Shenandoah: Rename ShenandoahHeapLock, make it general purpose lock Reviewed-by: shade ! src/share/vm/gc_implementation/shenandoah/shenandoahHeap.hpp - src/share/vm/gc_implementation/shenandoah/shenandoahHeapLock.hpp + src/share/vm/gc_implementation/shenandoah/shenandoahLock.hpp Changeset: 21d8d6bb2a5c Author: zgu Date: 2019-08-07 12:26 -0400 URL: https://hg.openjdk.java.net/aarch64-port/jdk8u-shenandoah/hotspot/rev/21d8d6bb2a5c [backport] 8229231: Shenandoah: Non-PCH builds failed after JDK-8224932 Reviewed-by: rkennke ! src/share/vm/gc_implementation/shenandoah/shenandoahLock.hpp Changeset: c1762d9e3797 Author: shade Date: 2019-10-17 20:56 +0200 URL: https://hg.openjdk.java.net/aarch64-port/jdk8u-shenandoah/hotspot/rev/c1762d9e3797 [backport] 8232534: Shenandoah: guard against reentrant ShenandoahHeapLock locking Reviewed-by: rkennke ! src/share/vm/gc_implementation/shenandoah/shenandoahLock.hpp Changeset: ecbb48f68293 Author: shade Date: 2019-10-17 20:56 +0200 URL: https://hg.openjdk.java.net/aarch64-port/jdk8u-shenandoah/hotspot/rev/ecbb48f68293 [backport] 8232573: Shenandoah: cleanup and add more logging for in-pause phases Reviewed-by: rkennke ! src/share/vm/gc_implementation/shenandoah/shenandoahHeap.cpp ! src/share/vm/gc_implementation/shenandoah/shenandoahPhaseTimings.hpp Changeset: c1fb0aea689b Author: shade Date: 2019-10-10 21:54 +0200 URL: https://hg.openjdk.java.net/aarch64-port/jdk8u-shenandoah/hotspot/rev/c1fb0aea689b [backport] 8231947: Shenandoah: cleanup ShenandoahHumongousMoves flag treatment Reviewed-by: rkennke ! src/share/vm/gc_implementation/shenandoah/shenandoahHeap.cpp ! src/share/vm/gc_implementation/shenandoah/shenandoahHeapRegion.hpp ! src/share/vm/gc_implementation/shenandoah/shenandoahMarkCompact.cpp ! src/share/vm/gc_implementation/shenandoah/shenandoah_globals.hpp + test/gc/shenandoah/options/TestHumongousMoves.java Changeset: e7d2bf49281b Author: shade Date: 2019-10-14 11:03 +0200 URL: https://hg.openjdk.java.net/aarch64-port/jdk8u-shenandoah/hotspot/rev/e7d2bf49281b [backport] 8232176: Shenandoah: new assert in ShenandoahEvacuationTask is too strong Reviewed-by: rkennke ! src/share/vm/gc_implementation/shenandoah/shenandoahHeap.cpp ! src/share/vm/gc_implementation/shenandoah/shenandoahHeapRegion.hpp Changeset: 6dd7867f6803 Author: shade Date: 2019-10-21 15:11 +0200 URL: https://hg.openjdk.java.net/aarch64-port/jdk8u-shenandoah/hotspot/rev/6dd7867f6803 [backport] 8232575: Shenandoah: asynchronous object/region pinning Reviewed-by: rkennke ! src/share/vm/gc_implementation/shenandoah/shenandoahHeap.cpp ! src/share/vm/gc_implementation/shenandoah/shenandoahHeap.hpp ! src/share/vm/gc_implementation/shenandoah/shenandoahHeapRegion.cpp ! src/share/vm/gc_implementation/shenandoah/shenandoahHeapRegion.hpp ! src/share/vm/gc_implementation/shenandoah/shenandoahHeuristics.cpp ! src/share/vm/gc_implementation/shenandoah/shenandoahMarkCompact.cpp ! src/share/vm/gc_implementation/shenandoah/shenandoahPhaseTimings.hpp Changeset: e9d60bdac4b5 Author: shade Date: 2019-10-22 18:53 +0200 URL: https://hg.openjdk.java.net/aarch64-port/jdk8u-shenandoah/hotspot/rev/e9d60bdac4b5 [backport] 8232802: Shenandoah: transition between "cset" and "pinned_cset" does not require cancelled gc Reviewed-by: zgu ! src/share/vm/gc_implementation/shenandoah/shenandoahHeapRegion.cpp Changeset: fc5e805d5afd Author: shade Date: 2019-06-07 11:48 +0200 URL: https://hg.openjdk.java.net/aarch64-port/jdk8u-shenandoah/hotspot/rev/fc5e805d5afd [backport] 8225441: Cleanup ShenandoahHeap::atomic_compare_exchange_oop Reviewed-by: rkennke ! src/share/vm/gc_implementation/shenandoah/shenandoahHeap.hpp ! src/share/vm/gc_implementation/shenandoah/shenandoahHeap.inline.hpp Changeset: 2ddc7cbee6ec Author: shade Date: 2019-10-21 22:44 +0200 URL: https://hg.openjdk.java.net/aarch64-port/jdk8u-shenandoah/hotspot/rev/2ddc7cbee6ec [backport] 8232729: Shenandoah: assert ShenandoahHeap::cas_oop addresses are aligned Reviewed-by: rkennke ! src/share/vm/gc_implementation/shenandoah/shenandoahHeap.inline.hpp Changeset: 474734121d2d Author: zgu Date: 2019-06-10 13:42 -0400 URL: https://hg.openjdk.java.net/aarch64-port/jdk8u-shenandoah/hotspot/rev/474734121d2d [backport] 8225514: Shenandoah: ShenandoahCodeRoots should inherit from AllStatic Reviewed-by: shade ! src/share/vm/gc_implementation/shenandoah/shenandoahCodeRoots.hpp Changeset: 9d889d13175e Author: shade Date: 2019-06-07 11:47 +0200 URL: https://hg.openjdk.java.net/aarch64-port/jdk8u-shenandoah/hotspot/rev/9d889d13175e [backport] 8225357: Rewire ShenandoahHeap::maybe_update_with_forwarded for contending fixups Reviewed-by: rkennke ! src/share/vm/gc_implementation/shenandoah/shenandoahConcurrentMark.inline.hpp ! src/share/vm/gc_implementation/shenandoah/shenandoahHeap.inline.hpp Changeset: 45c0ca785c61 Author: shade Date: 2019-10-10 21:54 +0200 URL: https://hg.openjdk.java.net/aarch64-port/jdk8u-shenandoah/hotspot/rev/45c0ca785c61 [backport] 8232102: Shenandoah: print everything in proper units Reviewed-by: rkennke ! src/share/vm/gc_implementation/shenandoah/heuristics/shenandoahAdaptiveHeuristics.cpp ! src/share/vm/gc_implementation/shenandoah/heuristics/shenandoahCompactHeuristics.cpp ! src/share/vm/gc_implementation/shenandoah/heuristics/shenandoahPassiveHeuristics.cpp ! src/share/vm/gc_implementation/shenandoah/heuristics/shenandoahStaticHeuristics.cpp ! src/share/vm/gc_implementation/shenandoah/shenandoahFreeSet.cpp ! src/share/vm/gc_implementation/shenandoah/shenandoahHeap.cpp ! src/share/vm/gc_implementation/shenandoah/shenandoahHeapRegion.cpp ! src/share/vm/gc_implementation/shenandoah/shenandoahHeuristics.cpp ! src/share/vm/gc_implementation/shenandoah/shenandoahPacer.cpp ! src/share/vm/gc_implementation/shenandoah/shenandoahVerifier.cpp Changeset: 989b374a7adf Author: shade Date: 2019-08-12 20:27 +0200 URL: https://hg.openjdk.java.net/aarch64-port/jdk8u-shenandoah/hotspot/rev/989b374a7adf [backport] 8229416: Shenandoah: Demote or remove ShenandoahOptimize*Final optimizations Reviewed-by: rkennke ! src/share/vm/ci/ciInstanceKlass.cpp ! src/share/vm/ci/ciInstanceKlass.hpp ! src/share/vm/gc_implementation/shenandoah/shenandoahSupport.cpp ! src/share/vm/gc_implementation/shenandoah/shenandoah_globals.hpp Changeset: 353f967c213d Author: shade Date: 2019-08-13 14:59 +0200 URL: https://hg.openjdk.java.net/aarch64-port/jdk8u-shenandoah/hotspot/rev/353f967c213d [backport] 8229419: Shenandoah: Cleanup LRB strength selector code Reviewed-by: rkennke ! src/share/vm/gc_implementation/shenandoah/shenandoahSupport.cpp ! src/share/vm/gc_implementation/shenandoah/shenandoahSupport.hpp Changeset: a56f86355f8d Author: shade Date: 2019-10-31 12:50 +0100 URL: https://hg.openjdk.java.net/aarch64-port/jdk8u-shenandoah/hotspot/rev/a56f86355f8d Shenandoah: JvmtiExport::weak_oops_do should not be entered by multiple threads ! src/share/vm/gc_implementation/shenandoah/shenandoahRootProcessor.cpp Changeset: 37548f3acb7c Author: shade Date: 2019-11-04 12:03 +0100 URL: https://hg.openjdk.java.net/aarch64-port/jdk8u-shenandoah/hotspot/rev/37548f3acb7c Fix naked heap loads in HeapDumper ! src/share/vm/services/heapDumper.cpp Changeset: e8582ad276a2 Author: shade Date: 2019-11-04 12:25 +0100 URL: https://hg.openjdk.java.net/aarch64-port/jdk8u-shenandoah/hotspot/rev/e8582ad276a2 Fix ifdef -> if INCLUDE_ALL_GCS in Shenandoah x86_32 code ! src/cpu/x86/vm/stubGenerator_x86_32.cpp ! src/cpu/x86/vm/templateInterpreter_x86_32.cpp ! src/cpu/x86/vm/templateTable_x86_32.cpp Changeset: aedd635caddf Author: shade Date: 2019-09-19 09:50 +0200 URL: https://hg.openjdk.java.net/aarch64-port/jdk8u-shenandoah/hotspot/rev/aedd635caddf Cherry-pick JDK-8231201: hs_err should print coalesced safepoint operations in Events section ! src/share/vm/runtime/vmThread.cpp Changeset: a8252208b533 Author: rkennke Date: 2019-11-08 10:58 +0100 URL: https://hg.openjdk.java.net/aarch64-port/jdk8u-shenandoah/hotspot/rev/a8252208b533 [backport] 8226757: Shenandoah: Make traversal and passive modes explicit ! src/share/vm/gc_implementation/shenandoah/heuristics/shenandoahAdaptiveHeuristics.cpp ! src/share/vm/gc_implementation/shenandoah/heuristics/shenandoahAdaptiveHeuristics.hpp ! src/share/vm/gc_implementation/shenandoah/heuristics/shenandoahAggressiveHeuristics.cpp ! src/share/vm/gc_implementation/shenandoah/heuristics/shenandoahAggressiveHeuristics.hpp ! src/share/vm/gc_implementation/shenandoah/heuristics/shenandoahCompactHeuristics.cpp ! src/share/vm/gc_implementation/shenandoah/heuristics/shenandoahCompactHeuristics.hpp ! src/share/vm/gc_implementation/shenandoah/heuristics/shenandoahPassiveHeuristics.cpp ! src/share/vm/gc_implementation/shenandoah/heuristics/shenandoahPassiveHeuristics.hpp ! src/share/vm/gc_implementation/shenandoah/heuristics/shenandoahStaticHeuristics.cpp ! src/share/vm/gc_implementation/shenandoah/heuristics/shenandoahStaticHeuristics.hpp ! src/share/vm/gc_implementation/shenandoah/shenandoahControlThread.cpp ! src/share/vm/gc_implementation/shenandoah/shenandoahHeap.cpp ! src/share/vm/gc_implementation/shenandoah/shenandoahHeap.hpp ! src/share/vm/gc_implementation/shenandoah/shenandoahHeuristics.cpp ! src/share/vm/gc_implementation/shenandoah/shenandoahHeuristics.hpp + src/share/vm/gc_implementation/shenandoah/shenandoahMode.hpp + src/share/vm/gc_implementation/shenandoah/shenandoahNormalMode.cpp + src/share/vm/gc_implementation/shenandoah/shenandoahNormalMode.hpp + src/share/vm/gc_implementation/shenandoah/shenandoahPassiveMode.cpp + src/share/vm/gc_implementation/shenandoah/shenandoahPassiveMode.hpp ! src/share/vm/gc_implementation/shenandoah/shenandoah_globals.hpp ! test/gc/shenandoah/TestAllocHumongousFragment.java ! test/gc/shenandoah/TestAllocIntArrays.java ! test/gc/shenandoah/TestAllocObjectArrays.java ! test/gc/shenandoah/TestAllocObjects.java ! test/gc/shenandoah/TestGCThreadGroups.java ! test/gc/shenandoah/TestHeapUncommit.java ! test/gc/shenandoah/TestLotsOfCycles.java ! test/gc/shenandoah/TestPeriodicGC.java ! test/gc/shenandoah/TestRegionSampling.java ! test/gc/shenandoah/TestRetainObjects.java ! test/gc/shenandoah/TestSieveObjects.java ! test/gc/shenandoah/TestStringDedup.java ! test/gc/shenandoah/TestStringDedupStress.java ! test/gc/shenandoah/TestStringInternCleanup.java ! test/gc/shenandoah/TestVerifyJCStress.java ! test/gc/shenandoah/jni/TestCriticalNativeArgs.sh ! test/gc/shenandoah/jni/TestCriticalNativeStress.sh ! test/gc/shenandoah/jni/TestJNIGlobalRefs.sh ! test/gc/shenandoah/jni/TestPinnedGarbage.sh ! test/gc/shenandoah/mxbeans/TestChurnNotifications.java ! test/gc/shenandoah/mxbeans/TestPauseNotifications.java ! test/gc/shenandoah/oom/TestClassLoaderLeak.java ! test/gc/shenandoah/options/TestHeuristicsUnlock.java ! test/gc/shenandoah/options/TestHumongousMoves.java ! test/gc/shenandoah/options/TestSelectiveBarrierFlags.java ! test/gc/shenandoah/options/TestWrongBarrierDisable.java Changeset: b4a4b8691f19 Author: rkennke Date: 2019-11-11 16:03 +0100 URL: https://hg.openjdk.java.net/aarch64-port/jdk8u-shenandoah/hotspot/rev/b4a4b8691f19 Backport per-region seqnum tracking ! src/share/vm/gc_implementation/shenandoah/shenandoahHeapRegion.cpp ! src/share/vm/gc_implementation/shenandoah/shenandoahHeapRegion.hpp ! src/share/vm/gc_implementation/shenandoah/shenandoahHeapRegion.inline.hpp ! src/share/vm/gc_implementation/shenandoah/shenandoahVerifier.cpp Changeset: 5935510ea5e7 Author: rkennke Date: 2019-11-11 16:09 +0100 URL: https://hg.openjdk.java.net/aarch64-port/jdk8u-shenandoah/hotspot/rev/5935510ea5e7 Backport Traversal GC ! src/cpu/aarch64/vm/sharedRuntime_aarch64.cpp ! src/cpu/aarch64/vm/shenandoahBarrierSetAssembler_aarch64.cpp ! src/cpu/aarch64/vm/shenandoahBarrierSetAssembler_aarch64.hpp ! src/cpu/aarch64/vm/templateInterpreter_aarch64.cpp ! src/cpu/aarch64/vm/templateTable_aarch64.cpp ! src/cpu/x86/vm/macroAssembler_x86.cpp ! src/cpu/x86/vm/shenandoahBarrierSetAssembler_x86.cpp ! src/cpu/x86/vm/shenandoahBarrierSetAssembler_x86.hpp ! src/cpu/x86/vm/templateInterpreter_x86_32.cpp ! src/cpu/x86/vm/templateInterpreter_x86_64.cpp ! src/cpu/x86/vm/templateTable_x86_32.cpp ! src/cpu/x86/vm/templateTable_x86_64.cpp ! src/share/vm/c1/c1_LIRGenerator.cpp ! src/share/vm/classfile/symbolTable.cpp ! src/share/vm/gc_implementation/shenandoah/heuristics/shenandoahAggressiveHeuristics.cpp ! src/share/vm/gc_implementation/shenandoah/heuristics/shenandoahCompactHeuristics.cpp ! src/share/vm/gc_implementation/shenandoah/heuristics/shenandoahStaticHeuristics.cpp + src/share/vm/gc_implementation/shenandoah/heuristics/shenandoahTraversalAggressiveHeuristics.cpp + src/share/vm/gc_implementation/shenandoah/heuristics/shenandoahTraversalAggressiveHeuristics.hpp + src/share/vm/gc_implementation/shenandoah/heuristics/shenandoahTraversalHeuristics.cpp + src/share/vm/gc_implementation/shenandoah/heuristics/shenandoahTraversalHeuristics.hpp ! src/share/vm/gc_implementation/shenandoah/shenandoahAsserts.cpp ! src/share/vm/gc_implementation/shenandoah/shenandoahBarrierSet.cpp ! src/share/vm/gc_implementation/shenandoah/shenandoahBarrierSet.hpp ! src/share/vm/gc_implementation/shenandoah/shenandoahBarrierSetC1.cpp ! src/share/vm/gc_implementation/shenandoah/shenandoahBarrierSetC1.hpp ! src/share/vm/gc_implementation/shenandoah/shenandoahClosures.inline.hpp ! src/share/vm/gc_implementation/shenandoah/shenandoahConcurrentMark.hpp ! src/share/vm/gc_implementation/shenandoah/shenandoahConcurrentMark.inline.hpp ! src/share/vm/gc_implementation/shenandoah/shenandoahControlThread.cpp ! src/share/vm/gc_implementation/shenandoah/shenandoahControlThread.hpp ! src/share/vm/gc_implementation/shenandoah/shenandoahFreeSet.cpp ! src/share/vm/gc_implementation/shenandoah/shenandoahHeap.cpp ! src/share/vm/gc_implementation/shenandoah/shenandoahHeap.hpp ! src/share/vm/gc_implementation/shenandoah/shenandoahHeap.inline.hpp ! src/share/vm/gc_implementation/shenandoah/shenandoahHeapRegion.cpp ! src/share/vm/gc_implementation/shenandoah/shenandoahHeapRegionCounters.cpp ! src/share/vm/gc_implementation/shenandoah/shenandoahHeapRegionCounters.hpp ! src/share/vm/gc_implementation/shenandoah/shenandoahHeuristics.cpp ! src/share/vm/gc_implementation/shenandoah/shenandoahHeuristics.hpp ! src/share/vm/gc_implementation/shenandoah/shenandoahMarkCompact.cpp ! src/share/vm/gc_implementation/shenandoah/shenandoahNormalMode.cpp + src/share/vm/gc_implementation/shenandoah/shenandoahOopClosures.cpp ! src/share/vm/gc_implementation/shenandoah/shenandoahOopClosures.hpp ! src/share/vm/gc_implementation/shenandoah/shenandoahOopClosures.inline.hpp ! src/share/vm/gc_implementation/shenandoah/shenandoahPacer.cpp ! src/share/vm/gc_implementation/shenandoah/shenandoahPacer.hpp ! src/share/vm/gc_implementation/shenandoah/shenandoahPassiveMode.cpp ! src/share/vm/gc_implementation/shenandoah/shenandoahPhaseTimings.cpp ! src/share/vm/gc_implementation/shenandoah/shenandoahPhaseTimings.hpp ! src/share/vm/gc_implementation/shenandoah/shenandoahTimingTracker.cpp + src/share/vm/gc_implementation/shenandoah/shenandoahTraversalGC.cpp + src/share/vm/gc_implementation/shenandoah/shenandoahTraversalGC.hpp + src/share/vm/gc_implementation/shenandoah/shenandoahTraversalGC.inline.hpp + src/share/vm/gc_implementation/shenandoah/shenandoahTraversalMode.cpp + src/share/vm/gc_implementation/shenandoah/shenandoahTraversalMode.hpp ! src/share/vm/gc_implementation/shenandoah/shenandoahUtils.cpp ! src/share/vm/gc_implementation/shenandoah/shenandoahUtils.hpp ! src/share/vm/gc_implementation/shenandoah/shenandoahVMOperations.cpp ! src/share/vm/gc_implementation/shenandoah/shenandoahVMOperations.hpp ! src/share/vm/gc_implementation/shenandoah/shenandoahVerifier.cpp ! src/share/vm/gc_implementation/shenandoah/shenandoahVerifier.hpp ! src/share/vm/gc_implementation/shenandoah/shenandoahWorkerPolicy.cpp ! src/share/vm/gc_implementation/shenandoah/shenandoahWorkerPolicy.hpp ! src/share/vm/gc_implementation/shenandoah/shenandoah_globals.hpp ! src/share/vm/gc_interface/gcCause.hpp ! src/share/vm/oops/oop.inline.hpp ! src/share/vm/opto/graphKit.cpp ! src/share/vm/opto/ifnode.cpp ! src/share/vm/prims/jni.cpp ! src/share/vm/prims/jvm.cpp ! src/share/vm/prims/jvmtiGetLoadedClasses.cpp ! src/share/vm/prims/jvmtiTagMap.cpp ! src/share/vm/prims/unsafe.cpp ! src/share/vm/runtime/arguments.cpp ! src/share/vm/runtime/jniHandles.cpp ! src/share/vm/runtime/thread.cpp ! src/share/vm/runtime/vm_operations.hpp ! test/gc/shenandoah/TestAllocHumongousFragment.java ! test/gc/shenandoah/TestAllocIntArrays.java ! test/gc/shenandoah/TestAllocObjectArrays.java ! test/gc/shenandoah/TestAllocObjects.java ! test/gc/shenandoah/TestGCThreadGroups.java ! test/gc/shenandoah/TestHeapUncommit.java ! test/gc/shenandoah/TestLotsOfCycles.java ! test/gc/shenandoah/TestPeriodicGC.java ! test/gc/shenandoah/TestRefprocSanity.java ! test/gc/shenandoah/TestRegionSampling.java ! test/gc/shenandoah/TestRetainObjects.java ! test/gc/shenandoah/TestSieveObjects.java ! test/gc/shenandoah/TestStringDedup.java ! test/gc/shenandoah/TestStringDedupStress.java ! test/gc/shenandoah/TestStringInternCleanup.java ! test/gc/shenandoah/TestVerifyJCStress.java ! test/gc/shenandoah/TestWrongArrayMember.java ! test/gc/shenandoah/jni/TestCriticalNativeArgs.sh ! test/gc/shenandoah/jni/TestCriticalNativeStress.sh ! test/gc/shenandoah/mxbeans/TestChurnNotifications.java ! test/gc/shenandoah/mxbeans/TestPauseNotifications.java ! test/gc/shenandoah/oom/TestClassLoaderLeak.java ! test/gc/shenandoah/options/TestExplicitGC.java ! test/gc/shenandoah/options/TestHeuristicsUnlock.java ! test/gc/shenandoah/options/TestWrongBarrierDisable.java Changeset: bd480a95ed11 Author: rkennke Date: 2019-11-12 22:22 +0100 URL: https://hg.openjdk.java.net/aarch64-port/jdk8u-shenandoah/hotspot/rev/bd480a95ed11 Revert obsolete shared-code changes in runtime synchronizer code ! src/share/vm/runtime/biasedLocking.cpp ! src/share/vm/runtime/synchronizer.cpp Changeset: 282516993f97 Author: rkennke Date: 2019-11-13 12:27 +0100 URL: https://hg.openjdk.java.net/aarch64-port/jdk8u-shenandoah/hotspot/rev/282516993f97 Remove some obsolete Shenandoah code from C2 ! src/share/vm/opto/addnode.cpp Changeset: 4095ba341695 Author: rkennke Date: 2019-11-13 21:37 +0100 URL: https://hg.openjdk.java.net/aarch64-port/jdk8u-shenandoah/hotspot/rev/4095ba341695 Add missing include in shenandoahOopClosures.cpp ! src/share/vm/gc_implementation/shenandoah/shenandoahOopClosures.cpp Changeset: e90e85d7d6bf Author: rkennke Date: 2019-11-14 22:35 +0100 URL: https://hg.openjdk.java.net/aarch64-port/jdk8u-shenandoah/hotspot/rev/e90e85d7d6bf Fix lock ordering issue when calling JVMTI GetLoadedClasses during marking ! src/share/vm/prims/jvmtiGetLoadedClasses.cpp ! test/TEST.groups + test/gc/shenandoah/jvmti/TestGetLoadedClasses.java + test/gc/shenandoah/jvmti/TestGetLoadedClasses.sh + test/gc/shenandoah/jvmti/libTestGetLoadedClasses.c Changeset: b9601b57b3c4 Author: rkennke Date: 2019-11-26 17:28 +0100 URL: https://hg.openjdk.java.net/aarch64-port/jdk8u-shenandoah/hotspot/rev/b9601b57b3c4 [backport] Remove to wrong handlings of Shenandoah LRB in escape analysis ! src/share/vm/opto/escape.cpp Changeset: 01040e94f1e9 Author: rkennke Date: 2019-11-26 22:29 +0100 URL: https://hg.openjdk.java.net/aarch64-port/jdk8u-shenandoah/hotspot/rev/01040e94f1e9 [backport] 8221435: Shenandoah should not mark through weak roots ! src/share/vm/gc_implementation/shenandoah/shenandoahConcurrentMark.cpp ! src/share/vm/gc_implementation/shenandoah/shenandoahHeap.cpp ! src/share/vm/gc_implementation/shenandoah/shenandoahHeap.hpp ! src/share/vm/gc_implementation/shenandoah/shenandoahMarkCompact.cpp ! src/share/vm/gc_implementation/shenandoah/shenandoahRootProcessor.cpp ! src/share/vm/gc_implementation/shenandoah/shenandoahRootProcessor.hpp ! src/share/vm/gc_implementation/shenandoah/shenandoahTraversalGC.cpp Changeset: 37af9ac9f204 Author: rkennke Date: 2019-12-09 13:30 +0100 URL: https://hg.openjdk.java.net/aarch64-port/jdk8u-shenandoah/hotspot/rev/37af9ac9f204 Merge ! src/cpu/aarch64/vm/aarch64.ad - src/cpu/aarch64/vm/shenandoahBarrierSet_aarch64.cpp - src/cpu/ppc/vm/shenandoahBarrierSet_ppc.cpp - src/cpu/sparc/vm/shenandoahBarrierSet_sparc.cpp - src/cpu/x86/vm/shenandoahBarrierSet_x86.cpp - src/cpu/zero/vm/shenandoahBarrierSet_zero.cpp - src/share/vm/gc_implementation/shenandoah/shenandoahBrooksPointer.hpp - src/share/vm/gc_implementation/shenandoah/shenandoahBrooksPointer.inline.hpp - src/share/vm/gc_implementation/shenandoah/shenandoahHeapLock.hpp - src/share/vm/opto/shenandoahSupport.cpp - src/share/vm/opto/shenandoahSupport.hpp Changeset: 9c888fe827f2 Author: zgu Date: 2019-12-10 10:58 -0500 URL: https://hg.openjdk.java.net/aarch64-port/jdk8u-shenandoah/hotspot/rev/9c888fe827f2 Shenandoah SA: support live region iteration Reviewed-by: rkennke ! agent/src/share/classes/sun/jvm/hotspot/gc_implementation/shenandoah/ShenandoahHeap.java ! agent/src/share/classes/sun/jvm/hotspot/oops/ObjectHeap.java ! src/share/vm/gc_implementation/shenandoah/vmStructs_shenandoah.hpp Changeset: c75c503b4aee Author: rkennke Date: 2019-12-12 13:06 +0100 URL: https://hg.openjdk.java.net/aarch64-port/jdk8u-shenandoah/hotspot/rev/c75c503b4aee Merge From aph at redhat.com Thu Dec 12 19:14:53 2019 From: aph at redhat.com (Andrew Haley) Date: Thu, 12 Dec 2019 19:14:53 +0000 Subject: [aarch64-port-dev ] RFR: 8235385: AArch64: Crash on aarch64 JDK due to long offset Message-ID: <154c82af-865f-d250-395d-6cb9b41b2780@redhat.com> This assertion failure happens because load/store patterns in aarch64.ad are incorrect. The operands immIOffset and operand immLoffset() are only correct for load/store *byte* offsets. Offsets of sizes greater than a byte should be shifted by the operand size, and misaligned offsets are only allowed for a small range. We get this wrong, so we try to use misaligned byte addresses for sizes greater than byte. This fails at compile time. We've never noticed this before because Java code doesn't generate misaligned offsets, so we can only test this fix by using Unsafe (or a customer of Unsafe such as ByteBuffer.) Wang Zhuo(Zhuoren) wrote a patch for this bug but it was incomplete; the problem reached deeper than we at first realized. Zhuoren's approach was to fix up the code generation after pattern matching, but this masks an efficiency problem. In many cases where we could use offset addresses, we don't because the pattern matcher incorrectly decides offsets are out of range. This patch fixes both problems by using memory types that are correct for all operand sizes. These are memory1, memory2, memory4, etc; this naming fits in with the existing types used by vectors. It does lead to a rather large patch, but it's not quite as bad as it looks because much of the code is auto-generated by the script ad_encode.m4. Unfortunately, in the time since it was written some developers have edited that auto-generated section of aarch64.ad by hand, so I had to move these hand edits out of the way. I also I have also added big scary // DO NOT EDIT ANYTHING IN THIS SECTION OF THE FILE comments so this doesn't happen again. In a rather belt-and-braces way I've also added some code that fixes up illegal addresses. I did consider removing it, but I left it in because it doesn't hurt. If we ever do generate similar illegal addresses, debug builds will assert. I'm not sure whether to keep this or not. Andrew Dinn will probably have a cow when he sees this patch. :-) OK for HEAD? -- Andrew Haley (he/him) Java Platform Lead Engineer Red Hat UK Ltd. https://keybase.io/andrewhaley EAC8 43EB D3EF DB98 CC77 2FAD A5CD 6035 332F A671 From zhuoren.wz at alibaba-inc.com Fri Dec 13 02:24:41 2019 From: zhuoren.wz at alibaba-inc.com (=?UTF-8?B?V2FuZyBaaHVvKFpodW9yZW4p?=) Date: Fri, 13 Dec 2019 10:24:41 +0800 Subject: [aarch64-port-dev ] =?utf-8?q?RFR=3A_8235385=3A_AArch64=3A_Crash_?= =?utf-8?q?on_aarch64_JDK_due=09to_long_offset?= In-Reply-To: <154c82af-865f-d250-395d-6cb9b41b2780@redhat.com> References: <154c82af-865f-d250-395d-6cb9b41b2780@redhat.com> Message-ID: <9448390e-8a43-485a-9060-ab3b7f4250fa.zhuoren.wz@alibaba-inc.com> OK for me. I also found this assertion failure also existed in load. A test for load was uploaded in JBS page. Regards, Zhuoren ------------------------------------------------------------------ From:Andrew Haley Sent At:2019 Dec. 13 (Fri.) 03:15 To:hotspot compiler ; aarch64-port-dev at openjdk.java.net Subject:[aarch64-port-dev ] RFR: 8235385: AArch64: Crash on aarch64 JDK due to long offset This assertion failure happens because load/store patterns in aarch64.ad are incorrect. The operands immIOffset and operand immLoffset() are only correct for load/store *byte* offsets. Offsets of sizes greater than a byte should be shifted by the operand size, and misaligned offsets are only allowed for a small range. We get this wrong, so we try to use misaligned byte addresses for sizes greater than byte. This fails at compile time. We've never noticed this before because Java code doesn't generate misaligned offsets, so we can only test this fix by using Unsafe (or a customer of Unsafe such as ByteBuffer.) Wang Zhuo(Zhuoren) wrote a patch for this bug but it was incomplete; the problem reached deeper than we at first realized. Zhuoren's approach was to fix up the code generation after pattern matching, but this masks an efficiency problem. In many cases where we could use offset addresses, we don't because the pattern matcher incorrectly decides offsets are out of range. This patch fixes both problems by using memory types that are correct for all operand sizes. These are memory1, memory2, memory4, etc; this naming fits in with the existing types used by vectors. It does lead to a rather large patch, but it's not quite as bad as it looks because much of the code is auto-generated by the script ad_encode.m4. Unfortunately, in the time since it was written some developers have edited that auto-generated section of aarch64.ad by hand, so I had to move these hand edits out of the way. I also I have also added big scary // DO NOT EDIT ANYTHING IN THIS SECTION OF THE FILE comments so this doesn't happen again. In a rather belt-and-braces way I've also added some code that fixes up illegal addresses. I did consider removing it, but I left it in because it doesn't hurt. If we ever do generate similar illegal addresses, debug builds will assert. I'm not sure whether to keep this or not. Andrew Dinn will probably have a cow when he sees this patch. :-) OK for HEAD? -- Andrew Haley (he/him) Java Platform Lead Engineer Red Hat UK Ltd. https://keybase.io/andrewhaley EAC8 43EB D3EF DB98 CC77 2FAD A5CD 6035 332F A671 From nick.gasson at arm.com Fri Dec 13 06:10:24 2019 From: nick.gasson at arm.com (Nick Gasson) Date: Fri, 13 Dec 2019 14:10:24 +0800 Subject: [aarch64-port-dev ] RFR: 8235385: AArch64: Crash on aarch64 JDK due to long offset In-Reply-To: <154c82af-865f-d250-395d-6cb9b41b2780@redhat.com> References: <154c82af-865f-d250-395d-6cb9b41b2780@redhat.com> Message-ID: <642bcb33-f02f-892b-d258-5ac537fdef4b@arm.com> On 13/12/2019 03:14, Andrew Haley wrote: > > This patch fixes both problems by using memory types that are correct > for all operand sizes. These are memory1, memory2, memory4, etc; this > naming fits in with the existing types used by vectors. > The RFR mail is missing a link to the webrev - is it this one? http://cr.openjdk.java.net/~aph/8235385/ Thanks, Nick From navy.xliu at gmail.com Thu Dec 12 19:51:17 2019 From: navy.xliu at gmail.com (Liu Xin) Date: Thu, 12 Dec 2019 11:51:17 -0800 Subject: [aarch64-port-dev ] does C1+CMS miss a storestore membar in jdk8u-shenandoah? In-Reply-To: <2b433414-fab1-c63d-1e07-76ddd4abe298@redhat.com> References: <2b433414-fab1-c63d-1e07-76ddd4abe298@redhat.com> Message-ID: hi, Martin and Andrew, Thank you to point out that JBS issue. I can backport and validate that. Yes, if powerpc doesn't have C1 in jdk8u, than it's safe. it's only about aarch64. thanks, --lx On Thu, Dec 12, 2019 at 2:18 AM Andrew Haley wrote: > On 12/12/19 9:36 AM, Doerr, Martin wrote: > > seems like the following issue should get backported: > > https://bugs.openjdk.java.net/browse/JDK-8135018 > > > > Btw. I believe PPC is fine because C1 is not supported in 8u (at least > not in the official repo). > > Oh yes, that's one of mine. We should backport it. > > -- > Andrew Haley (he/him) > Java Platform Lead Engineer > Red Hat UK Ltd. > https://keybase.io/andrewhaley > EAC8 43EB D3EF DB98 CC77 2FAD A5CD 6035 332F A671 > > From navy.xliu at gmail.com Fri Dec 13 08:48:25 2019 From: navy.xliu at gmail.com (Liu Xin) Date: Fri, 13 Dec 2019 00:48:25 -0800 Subject: [aarch64-port-dev ] RFR 8135018: AARCH64: Missing memory barriers for CMS collector In-Reply-To: References: <2b433414-fab1-c63d-1e07-76ddd4abe298@redhat.com> Message-ID: Hi, Aarch64 reviewers, May I ask to review this backport? bugs: https://bugs.openjdk.java.net/browse/JDK-8135018 webrev: https://cr.openjdk.java.net/~xliu/8135018/00/webrev/ I can't cleanly apply the original patch, but it isn't hard to adapt it. This patch also brings UseCondCardMark to C1 and template interpreter, which is consistent with C2. For validation part, I passed hotspot:tier1 test and jcstress with UseConcMarkSweepGC on an aarch64 machine. thanks, --lx On Thu, Dec 12, 2019 at 11:51 AM Liu Xin wrote: > hi, Martin and Andrew, > > Thank you to point out that JBS issue. I can backport and validate that. > Yes, if powerpc doesn't have C1 in jdk8u, than it's safe. it's only about > aarch64. > > thanks, > --lx > > > On Thu, Dec 12, 2019 at 2:18 AM Andrew Haley wrote: > >> On 12/12/19 9:36 AM, Doerr, Martin wrote: >> > seems like the following issue should get backported: >> > https://bugs.openjdk.java.net/browse/JDK-8135018 >> > >> > Btw. I believe PPC is fine because C1 is not supported in 8u (at least >> not in the official repo). >> >> Oh yes, that's one of mine. We should backport it. >> >> -- >> Andrew Haley (he/him) >> Java Platform Lead Engineer >> Red Hat UK Ltd. >> https://keybase.io/andrewhaley >> EAC8 43EB D3EF DB98 CC77 2FAD A5CD 6035 332F A671 >> >> From aph at redhat.com Fri Dec 13 09:31:23 2019 From: aph at redhat.com (Andrew Haley) Date: Fri, 13 Dec 2019 09:31:23 +0000 Subject: [aarch64-port-dev ] Fwd: RFR: 8235385: AArch64: Crash on aarch64 JDK due to long offset In-Reply-To: <154c82af-865f-d250-395d-6cb9b41b2780@redhat.com> References: <154c82af-865f-d250-395d-6cb9b41b2780@redhat.com> Message-ID: http://cr.openjdk.java.net/~aph/8235385/ -- Andrew Haley (he/him) Java Platform Lead Engineer Red Hat UK Ltd. https://keybase.io/andrewhaley EAC8 43EB D3EF DB98 CC77 2FAD A5CD 6035 332F A671 -------------- next part -------------- An embedded message was scrubbed... From: Andrew Haley Subject: [aarch64-port-dev ] RFR: 8235385: AArch64: Crash on aarch64 JDK due to long offset Date: Thu, 12 Dec 2019 19:14:53 +0000 Size: 12171 URL: From aph at redhat.com Fri Dec 13 09:31:45 2019 From: aph at redhat.com (Andrew Haley) Date: Fri, 13 Dec 2019 09:31:45 +0000 Subject: [aarch64-port-dev ] RFR: 8235385: AArch64: Crash on aarch64 JDK due to long offset In-Reply-To: <642bcb33-f02f-892b-d258-5ac537fdef4b@arm.com> References: <154c82af-865f-d250-395d-6cb9b41b2780@redhat.com> <642bcb33-f02f-892b-d258-5ac537fdef4b@arm.com> Message-ID: <1ac65be6-2aa3-6697-46b5-5eec5f52a48e@redhat.com> On 12/13/19 6:10 AM, Nick Gasson wrote: > On 13/12/2019 03:14, Andrew Haley wrote: >> >> This patch fixes both problems by using memory types that are correct >> for all operand sizes. These are memory1, memory2, memory4, etc; this >> naming fits in with the existing types used by vectors. >> > > The RFR mail is missing a link to the webrev - is it this one? > > http://cr.openjdk.java.net/~aph/8235385/ Yes, sorry. -- Andrew Haley (he/him) Java Platform Lead Engineer Red Hat UK Ltd. https://keybase.io/andrewhaley EAC8 43EB D3EF DB98 CC77 2FAD A5CD 6035 332F A671 From aph at redhat.com Fri Dec 13 09:43:52 2019 From: aph at redhat.com (Andrew Haley) Date: Fri, 13 Dec 2019 09:43:52 +0000 Subject: [aarch64-port-dev ] RFR 8135018: AARCH64: Missing memory barriers for CMS collector In-Reply-To: References: <2b433414-fab1-c63d-1e07-76ddd4abe298@redhat.com> Message-ID: <42729c1e-f90a-2a8d-cd48-c50e7a160245@redhat.com> On 12/13/19 8:48 AM, Liu Xin wrote: > May I ask to review this backport? > > bugs: https://bugs.openjdk.java.net/browse/JDK-8135018 > webrev: https://cr.openjdk.java.net/~xliu/8135018/00/webrev/ > > I can't cleanly apply the original patch, but it isn't hard to adapt it. > This patch also brings UseCondCardMark to C1 and template interpreter, > which is consistent with C2. > > For validation part, I passed hotspot:tier1 test and jcstress with > UseConcMarkSweepGC on an aarch64 machine. That seems like a lot more than simply adding memory barriers. Looks like the UseCondCardMark code is missing altogether. I can't remember the history of this; I'm concerned that there may be other missing hunks. -- Andrew Haley (he/him) Java Platform Lead Engineer Red Hat UK Ltd. https://keybase.io/andrewhaley EAC8 43EB D3EF DB98 CC77 2FAD A5CD 6035 332F A671 From martin.doerr at sap.com Fri Dec 13 13:38:04 2019 From: martin.doerr at sap.com (Doerr, Martin) Date: Fri, 13 Dec 2019 13:38:04 +0000 Subject: [aarch64-port-dev ] RFR 8135018: AARCH64: Missing memory barriers for CMS collector In-Reply-To: <42729c1e-f90a-2a8d-cd48-c50e7a160245@redhat.com> References: <2b433414-fab1-c63d-1e07-76ddd4abe298@redhat.com> <42729c1e-f90a-2a8d-cd48-c50e7a160245@redhat.com> Message-ID: Hi, I guess the change would apply cleanly on top of http://hg.openjdk.java.net/jdk9/jdk9/hotspot/rev/4a179f93d775 If it's easy to backport (I haven't tried) doing that one first should be the preferred way. But if that change is not wanted in 8u, I'll be fine with Ix's version. Having the UseCondCardMark code only at some places wouldn't break anything. There's no consistency requirement. Best regards, Martin > -----Original Message----- > From: Andrew Haley > Sent: Freitag, 13. Dezember 2019 10:44 > To: Liu Xin > Cc: Doerr, Martin ; aarch64-port- > dev at openjdk.java.net > Subject: Re: RFR 8135018: AARCH64: Missing memory barriers for CMS > collector > > On 12/13/19 8:48 AM, Liu Xin wrote: > > May I ask to review this backport? > > > > bugs: https://bugs.openjdk.java.net/browse/JDK-8135018 > > webrev: https://cr.openjdk.java.net/~xliu/8135018/00/webrev/ > > > > I can't cleanly apply the original patch, but it isn't hard to adapt it. > > This patch also brings UseCondCardMark to C1 and template interpreter, > > which is consistent with C2. > > > > For validation part, I passed hotspot:tier1 test and jcstress with > > UseConcMarkSweepGC on an aarch64 machine. > > That seems like a lot more than simply adding memory barriers. Looks like > the UseCondCardMark code is missing altogether. > > I can't remember the history of this; I'm concerned that there may be other > missing hunks. > > -- > Andrew Haley (he/him) > Java Platform Lead Engineer > Red Hat UK Ltd. > https://keybase.io/andrewhaley > EAC8 43EB D3EF DB98 CC77 2FAD A5CD 6035 332F A671 From aph at redhat.com Fri Dec 13 15:21:27 2019 From: aph at redhat.com (Andrew Haley) Date: Fri, 13 Dec 2019 15:21:27 +0000 Subject: [aarch64-port-dev ] RFR 8135018: AARCH64: Missing memory barriers for CMS collector In-Reply-To: References: <2b433414-fab1-c63d-1e07-76ddd4abe298@redhat.com> <42729c1e-f90a-2a8d-cd48-c50e7a160245@redhat.com> Message-ID: On 12/13/19 1:38 PM, Doerr, Martin wrote: > I guess the change would apply cleanly on top of > http://hg.openjdk.java.net/jdk9/jdk9/hotspot/rev/4a179f93d775 > > If it's easy to backport (I haven't tried) doing that one first should be the preferred way. > > But if that change is not wanted in 8u, I'll be fine with Ix's version. > Having the UseCondCardMark code only at some places wouldn't break anything. There's no consistency requirement. OK, but I'm trying to understand what is going on. Either UseCondCardMark is supported by AArch64 in JDK 8 or it is not. If it is not, then all we have to do is insert any missing memory barriers. If it's supposed to be, then we should be consistent. -- Andrew Haley (he/him) Java Platform Lead Engineer Red Hat UK Ltd. https://keybase.io/andrewhaley EAC8 43EB D3EF DB98 CC77 2FAD A5CD 6035 332F A671 From gnu.andrew at redhat.com Fri Dec 13 18:01:25 2019 From: gnu.andrew at redhat.com (gnu.andrew at redhat.com) Date: Fri, 13 Dec 2019 18:01:25 +0000 Subject: [aarch64-port-dev ] hg: aarch64-port/jdk8u-shenandoah: 7 new changesets Message-ID: <201912131801.xBDI1P9g001870@aojmv0008.oracle.com> Changeset: 42434f847608 Author: andrew Date: 2019-10-15 21:37 +0100 URL: https://hg.openjdk.java.net/aarch64-port/jdk8u-shenandoah/rev/42434f847608 Added tag jdk8u232-ga for changeset 6b9f309807a2 ! .hgtags Changeset: 63d8d852b127 Author: andrew Date: 2019-09-06 03:21 +0100 URL: https://hg.openjdk.java.net/aarch64-port/jdk8u-shenandoah/rev/63d8d852b127 Added tag jdk8u242-b00 for changeset a29e19e1c0ee ! .hgtags Changeset: 4ca097c49b1b Author: zgu Date: 2019-09-12 15:20 -0400 URL: https://hg.openjdk.java.net/aarch64-port/jdk8u-shenandoah/rev/4ca097c49b1b 8217676: Upgrade libpng to 1.6.37 Reviewed-by: prr, jdv, kcr ! THIRD_PARTY_README Changeset: 34aa7bcd731f Author: andrew Date: 2019-10-17 13:46 +0100 URL: https://hg.openjdk.java.net/aarch64-port/jdk8u-shenandoah/rev/34aa7bcd731f Merge ! .hgtags Changeset: d20799349800 Author: andrew Date: 2019-11-08 16:49 +0000 URL: https://hg.openjdk.java.net/aarch64-port/jdk8u-shenandoah/rev/d20799349800 Added tag jdk8u242-b01 for changeset 34aa7bcd731f ! .hgtags Changeset: b7b59f2e50fc Author: andrew Date: 2019-11-08 18:16 +0000 URL: https://hg.openjdk.java.net/aarch64-port/jdk8u-shenandoah/rev/b7b59f2e50fc Merge jdk8u242-b01 ! .hgtags Changeset: bada420f74f8 Author: andrew Date: 2019-11-08 18:16 +0000 URL: https://hg.openjdk.java.net/aarch64-port/jdk8u-shenandoah/rev/bada420f74f8 Added tag aarch64-shenandoah-jdk8u242-b01 for changeset b7b59f2e50fc ! .hgtags From gnu.andrew at redhat.com Fri Dec 13 18:04:38 2019 From: gnu.andrew at redhat.com (gnu.andrew at redhat.com) Date: Fri, 13 Dec 2019 18:04:38 +0000 Subject: [aarch64-port-dev ] hg: aarch64-port/jdk8u-shenandoah/corba: 7 new changesets Message-ID: <201912131804.xBDI4dpu002940@aojmv0008.oracle.com> Changeset: 870b3cd9fc18 Author: andrew Date: 2019-10-15 21:37 +0100 URL: https://hg.openjdk.java.net/aarch64-port/jdk8u-shenandoah/corba/rev/870b3cd9fc18 Added tag jdk8u232-ga for changeset 3cdc7d41905a ! .hgtags Changeset: 4e517b4adab4 Author: andrew Date: 2019-09-06 03:21 +0100 URL: https://hg.openjdk.java.net/aarch64-port/jdk8u-shenandoah/corba/rev/4e517b4adab4 Added tag jdk8u242-b00 for changeset 75ad72ef4f68 ! .hgtags Changeset: 75fe7bdb490f Author: zgu Date: 2019-09-12 15:20 -0400 URL: https://hg.openjdk.java.net/aarch64-port/jdk8u-shenandoah/corba/rev/75fe7bdb490f 8217676: Upgrade libpng to 1.6.37 Reviewed-by: prr, jdv, kcr ! THIRD_PARTY_README Changeset: d4d4f7f07a86 Author: andrew Date: 2019-10-17 13:46 +0100 URL: https://hg.openjdk.java.net/aarch64-port/jdk8u-shenandoah/corba/rev/d4d4f7f07a86 Merge ! .hgtags Changeset: b3fbd77f16f6 Author: andrew Date: 2019-11-08 16:49 +0000 URL: https://hg.openjdk.java.net/aarch64-port/jdk8u-shenandoah/corba/rev/b3fbd77f16f6 Added tag jdk8u242-b01 for changeset d4d4f7f07a86 ! .hgtags Changeset: cfd920ae9cf4 Author: andrew Date: 2019-11-08 18:16 +0000 URL: https://hg.openjdk.java.net/aarch64-port/jdk8u-shenandoah/corba/rev/cfd920ae9cf4 Merge jdk8u242-b01 ! .hgtags Changeset: f0261e3f20f7 Author: andrew Date: 2019-11-08 18:16 +0000 URL: https://hg.openjdk.java.net/aarch64-port/jdk8u-shenandoah/corba/rev/f0261e3f20f7 Added tag aarch64-shenandoah-jdk8u242-b01 for changeset cfd920ae9cf4 ! .hgtags From gnu.andrew at redhat.com Fri Dec 13 18:42:37 2019 From: gnu.andrew at redhat.com (gnu.andrew at redhat.com) Date: Fri, 13 Dec 2019 18:42:37 +0000 Subject: [aarch64-port-dev ] hg: aarch64-port/jdk8u-shenandoah/jaxp: 7 new changesets Message-ID: <201912131842.xBDIgbmR024575@aojmv0008.oracle.com> Changeset: f12bc79922f2 Author: andrew Date: 2019-10-15 21:37 +0100 URL: https://hg.openjdk.java.net/aarch64-port/jdk8u-shenandoah/jaxp/rev/f12bc79922f2 Added tag jdk8u232-ga for changeset 6f9c0c731ab7 ! .hgtags Changeset: 4d49e08bb0a0 Author: andrew Date: 2019-09-06 03:21 +0100 URL: https://hg.openjdk.java.net/aarch64-port/jdk8u-shenandoah/jaxp/rev/4d49e08bb0a0 Added tag jdk8u242-b00 for changeset 7b44b5f468a4 ! .hgtags Changeset: 187f73676840 Author: zgu Date: 2019-09-12 15:21 -0400 URL: https://hg.openjdk.java.net/aarch64-port/jdk8u-shenandoah/jaxp/rev/187f73676840 8217676: Upgrade libpng to 1.6.37 Reviewed-by: prr, jdv, kcr ! THIRD_PARTY_README Changeset: 6e9f5f2c620a Author: andrew Date: 2019-10-17 13:47 +0100 URL: https://hg.openjdk.java.net/aarch64-port/jdk8u-shenandoah/jaxp/rev/6e9f5f2c620a Merge ! .hgtags Changeset: 91cff4cef209 Author: andrew Date: 2019-11-08 16:49 +0000 URL: https://hg.openjdk.java.net/aarch64-port/jdk8u-shenandoah/jaxp/rev/91cff4cef209 Added tag jdk8u242-b01 for changeset 6e9f5f2c620a ! .hgtags Changeset: 891be6de3bfb Author: andrew Date: 2019-11-08 18:16 +0000 URL: https://hg.openjdk.java.net/aarch64-port/jdk8u-shenandoah/jaxp/rev/891be6de3bfb Merge jdk8u242-b01 ! .hgtags Changeset: e18e5327f4fa Author: andrew Date: 2019-11-08 18:16 +0000 URL: https://hg.openjdk.java.net/aarch64-port/jdk8u-shenandoah/jaxp/rev/e18e5327f4fa Added tag aarch64-shenandoah-jdk8u242-b01 for changeset 891be6de3bfb ! .hgtags From gnu.andrew at redhat.com Fri Dec 13 19:13:18 2019 From: gnu.andrew at redhat.com (gnu.andrew at redhat.com) Date: Fri, 13 Dec 2019 19:13:18 +0000 Subject: [aarch64-port-dev ] hg: aarch64-port/jdk8u-shenandoah/jaxws: 7 new changesets Message-ID: <201912131913.xBDJDI6c012412@aojmv0008.oracle.com> Changeset: 12a8cc271ea2 Author: andrew Date: 2019-10-15 21:37 +0100 URL: https://hg.openjdk.java.net/aarch64-port/jdk8u-shenandoah/jaxws/rev/12a8cc271ea2 Added tag jdk8u232-ga for changeset 5f799cd7fe51 ! .hgtags Changeset: 0d1e2b9f787f Author: andrew Date: 2019-09-06 03:21 +0100 URL: https://hg.openjdk.java.net/aarch64-port/jdk8u-shenandoah/jaxws/rev/0d1e2b9f787f Added tag jdk8u242-b00 for changeset 60e3a82a9973 ! .hgtags Changeset: 55ba417a94a3 Author: zgu Date: 2019-09-12 15:22 -0400 URL: https://hg.openjdk.java.net/aarch64-port/jdk8u-shenandoah/jaxws/rev/55ba417a94a3 8217676: Upgrade libpng to 1.6.37 Reviewed-by: prr, jdv, kcr ! THIRD_PARTY_README Changeset: 3a911ec83c7e Author: andrew Date: 2019-10-17 13:47 +0100 URL: https://hg.openjdk.java.net/aarch64-port/jdk8u-shenandoah/jaxws/rev/3a911ec83c7e Merge ! .hgtags Changeset: 016be7bdaa27 Author: andrew Date: 2019-11-08 16:49 +0000 URL: https://hg.openjdk.java.net/aarch64-port/jdk8u-shenandoah/jaxws/rev/016be7bdaa27 Added tag jdk8u242-b01 for changeset 3a911ec83c7e ! .hgtags Changeset: 84ab39eddef6 Author: andrew Date: 2019-11-08 18:16 +0000 URL: https://hg.openjdk.java.net/aarch64-port/jdk8u-shenandoah/jaxws/rev/84ab39eddef6 Merge jdk8u242-b01 ! .hgtags Changeset: f7909d69c37a Author: andrew Date: 2019-11-08 18:16 +0000 URL: https://hg.openjdk.java.net/aarch64-port/jdk8u-shenandoah/jaxws/rev/f7909d69c37a Added tag aarch64-shenandoah-jdk8u242-b01 for changeset 84ab39eddef6 ! .hgtags From ci_notify at linaro.org Sat Dec 14 10:19:01 2019 From: ci_notify at linaro.org (ci_notify at linaro.org) Date: Sat, 14 Dec 2019 10:19:01 +0000 (UTC) Subject: [aarch64-port-dev ] JTREG, JCStress, SPECjbb2015 and Hadoop/Terasort results for OpenJDK JDK on AArch64 Message-ID: <1167952641.4693.1576318741686.JavaMail.javamailuser@localhost> This is a summary of the JTREG test results =========================================== The build and test results are cycled every 15 days. For detailed information on the test output please refer to: http://openjdk.linaro.org/jdkX/openjdk-jtreg-nightly-tests/summary/2019/347/summary.html ------------------------------------------------------------------------------- client-release/hotspot ------------------------------------------------------------------------------- Build 0: aarch64/2018/oct/15 pass: 5,780; fail: 19; not run: 90 ------------------------------------------------------------------------------- client-release/jdk ------------------------------------------------------------------------------- Build 0: aarch64/2018/oct/15 pass: 8,495; fail: 670; error: 23 ------------------------------------------------------------------------------- client-release/langtools ------------------------------------------------------------------------------- Build 0: aarch64/2018/oct/15 pass: 3,970; fail: 5 ------------------------------------------------------------------------------- release/hotspot ------------------------------------------------------------------------------- Build 0: aarch64/2019/nov/11 pass: 5,762 Build 1: aarch64/2019/nov/13 pass: 5,764; fail: 1 Build 2: aarch64/2019/nov/15 pass: 5,750 Build 3: aarch64/2019/nov/18 pass: 5,750; fail: 1 Build 4: aarch64/2019/nov/20 pass: 5,752 Build 5: aarch64/2019/nov/22 pass: 5,752; fail: 1 Build 6: aarch64/2019/nov/25 pass: 5,752; fail: 1 Build 7: aarch64/2019/nov/27 pass: 5,752; fail: 2 Build 8: aarch64/2019/nov/29 pass: 5,752; fail: 2 Build 9: aarch64/2019/dec/02 pass: 5,753; fail: 4 Build 10: aarch64/2019/dec/04 pass: 5,755; fail: 2 Build 11: aarch64/2019/dec/07 pass: 5,762; fail: 1 Build 12: aarch64/2019/dec/09 pass: 5,762; fail: 1 Build 13: aarch64/2019/dec/11 pass: 5,765; fail: 44 Build 14: aarch64/2019/dec/13 pass: 5,765; fail: 45 1 fatal errors were detected; please follow the link above for more detail. ------------------------------------------------------------------------------- release/jdk ------------------------------------------------------------------------------- Build 0: aarch64/2019/nov/11 pass: 8,777; fail: 509; error: 15 Build 1: aarch64/2019/nov/13 pass: 8,773; fail: 509; error: 21 Build 2: aarch64/2019/nov/15 pass: 8,756; fail: 511; error: 19 Build 3: aarch64/2019/nov/18 pass: 8,765; fail: 504; error: 18 Build 4: aarch64/2019/nov/20 pass: 8,768; fail: 504; error: 19 Build 5: aarch64/2019/nov/22 pass: 8,769; fail: 507; error: 18 Build 6: aarch64/2019/nov/25 pass: 8,775; fail: 509; error: 17 Build 7: aarch64/2019/nov/27 pass: 8,779; fail: 506; error: 22 Build 8: aarch64/2019/nov/29 pass: 8,784; fail: 503; error: 20 Build 9: aarch64/2019/dec/02 pass: 8,784; fail: 507; error: 19 Build 10: aarch64/2019/dec/04 pass: 8,788; fail: 505; error: 17 Build 11: aarch64/2019/dec/07 pass: 8,819; fail: 524; error: 17 Build 12: aarch64/2019/dec/09 pass: 8,820; fail: 519; error: 21 Build 13: aarch64/2019/dec/11 pass: 8,818; fail: 520; error: 18 Build 14: aarch64/2019/dec/13 pass: 8,811; fail: 530; error: 17 4 fatal errors were detected; please follow the link above for more detail. ------------------------------------------------------------------------------- release/langtools ------------------------------------------------------------------------------- Build 0: aarch64/2019/nov/11 pass: 3,980 Build 1: aarch64/2019/nov/13 pass: 3,980 Build 2: aarch64/2019/nov/15 pass: 3,981 Build 3: aarch64/2019/nov/18 pass: 3,981 Build 4: aarch64/2019/nov/20 pass: 3,981 Build 5: aarch64/2019/nov/22 pass: 3,981 Build 6: aarch64/2019/nov/25 pass: 3,983 Build 7: aarch64/2019/nov/27 pass: 4,006 Build 8: aarch64/2019/nov/29 pass: 4,006 Build 9: aarch64/2019/dec/02 pass: 4,002; fail: 5; error: 1 Build 10: aarch64/2019/dec/04 pass: 4,008 Build 11: aarch64/2019/dec/07 pass: 4,019 Build 12: aarch64/2019/dec/09 pass: 4,019 Build 13: aarch64/2019/dec/11 pass: 4,021 Build 14: aarch64/2019/dec/13 pass: 4,029 ------------------------------------------------------------------------------- server-release/hotspot ------------------------------------------------------------------------------- Build 0: aarch64/2018/oct/15 pass: 5,787; fail: 18; not run: 90 ------------------------------------------------------------------------------- server-release/jdk ------------------------------------------------------------------------------- Build 0: aarch64/2018/oct/15 pass: 8,476; fail: 686; error: 27 ------------------------------------------------------------------------------- server-release/langtools ------------------------------------------------------------------------------- Build 0: aarch64/2018/oct/15 pass: 3,970; fail: 5 Previous results can be found here: http://openjdk.linaro.org/jdkX/openjdk-jtreg-nightly-tests/index.html SPECjbb2015 composite regression test completed =============================================== This test measures the relative performance of the server compiler running the SPECjbb2015 composite tests and compares the performance against the baseline performance of the server compiler taken on 2016-11-21. In accordance with [1], the SPECjbb2015 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): 8.04x Relative performance: Server critical-jOPS (nc): 12.44x Details of the test setup and historical results may be found here: http://openjdk.linaro.org/jdkX/SPECjbb2015-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 server compiler on 2014-04-01. Relative performance: Zero: 1.0, Server: 207.57 Server 207.57 / Server 2014-04-01 (71.00): 2.92x Details of the test setup and historical results may be found here: http://openjdk.linaro.org/jdkX/hadoop-terasort-benchmark-results/ This is a summary of the jcstress test results ============================================== The build and test results are cycled every 15 days. 2019-11-12 pass rate: 10490/10490, results: http://openjdk.linaro.org/jdkX/jcstress-nightly-runs/2019/315/results/ 2019-11-14 pass rate: 10490/10490, results: http://openjdk.linaro.org/jdkX/jcstress-nightly-runs/2019/317/results/ 2019-11-16 pass rate: 10490/10490, results: http://openjdk.linaro.org/jdkX/jcstress-nightly-runs/2019/319/results/ 2019-11-19 pass rate: 10490/10490, results: http://openjdk.linaro.org/jdkX/jcstress-nightly-runs/2019/322/results/ 2019-11-21 pass rate: 10490/10490, results: http://openjdk.linaro.org/jdkX/jcstress-nightly-runs/2019/324/results/ 2019-11-23 pass rate: 10490/10490, results: http://openjdk.linaro.org/jdkX/jcstress-nightly-runs/2019/326/results/ 2019-11-26 pass rate: 10490/10490, results: http://openjdk.linaro.org/jdkX/jcstress-nightly-runs/2019/329/results/ 2019-12-03 pass rate: 10490/10490, results: http://openjdk.linaro.org/jdkX/jcstress-nightly-runs/2019/331/results/ 2019-12-04 pass rate: 10490/10490, results: http://openjdk.linaro.org/jdkX/jcstress-nightly-runs/2019/333/results/ 2019-12-05 pass rate: 10490/10490, results: http://openjdk.linaro.org/jdkX/jcstress-nightly-runs/2019/336/results/ 2019-12-07 pass rate: 10490/10490, results: http://openjdk.linaro.org/jdkX/jcstress-nightly-runs/2019/338/results/ 2019-12-08 pass rate: 10490/10490, results: http://openjdk.linaro.org/jdkX/jcstress-nightly-runs/2019/341/results/ 2019-12-10 pass rate: 10490/10490, results: http://openjdk.linaro.org/jdkX/jcstress-nightly-runs/2019/343/results/ 2019-12-12 pass rate: 10490/10490, results: http://openjdk.linaro.org/jdkX/jcstress-nightly-runs/2019/345/results/ 2019-12-14 pass rate: 10490/10490, results: http://openjdk.linaro.org/jdkX/jcstress-nightly-runs/2019/347/results/ For detailed information on the test output please refer to: http://openjdk.linaro.org/jdkX/jcstress-nightly-runs/ From aph at redhat.com Sat Dec 14 22:18:04 2019 From: aph at redhat.com (Andrew Haley) Date: Sat, 14 Dec 2019 22:18:04 +0000 Subject: [aarch64-port-dev ] RFR 8135018: AARCH64: Missing memory barriers for CMS collector In-Reply-To: References: <2b433414-fab1-c63d-1e07-76ddd4abe298@redhat.com> <42729c1e-f90a-2a8d-cd48-c50e7a160245@redhat.com> Message-ID: <9cb488f4-a534-bc63-961f-6e676dd7b409@redhat.com> On 12/14/19 4:47 AM, Liu Xin wrote: > I trace the feature UseCondCardMark. It was > introduced by the following changes. > https://bugs.openjdk.java.net/browse/JDK-8076987 C1 > https://bugs.openjdk.java.net/browse/JDK-8078438 interpreter > UseCondCardMark is only supported by C2 currently. Yes, my original patch > does miss hunk -- the x86 part. That's why I propose a new webrev here. > It's almost a clean backport for JDK-8135018. Let's solve the missing > barrier bug first. Could you take a look at it? > https://cr.openjdk.java.net/~xliu/8135018/01/webrev/ That's OK, thanks. -- Andrew Haley (he/him) Java Platform Lead Engineer Red Hat UK Ltd. https://keybase.io/andrewhaley EAC8 43EB D3EF DB98 CC77 2FAD A5CD 6035 332F A671 From ci_notify at linaro.org Sun Dec 15 23:55:59 2019 From: ci_notify at linaro.org (ci_notify at linaro.org) Date: Sun, 15 Dec 2019 23:55:59 +0000 (UTC) Subject: [aarch64-port-dev ] JTREG, JCStress, SPECjbb2015 and Hadoop/Terasort results for OpenJDK 13 on AArch64 Message-ID: <1734968365.4927.1576454159914.JavaMail.javamailuser@localhost> This is a summary of the JTREG test results =========================================== The build and test results are cycled every 15 days. For detailed information on the test output please refer to: http://openjdk.linaro.org/jdk13/openjdk-jtreg-nightly-tests/summary/2019/348/summary.html ------------------------------------------------------------------------------- release/hotspot ------------------------------------------------------------------------------- Build 0: aarch64/2019/jul/18 pass: 5,644; fail: 2; error: 1 Build 1: aarch64/2019/jul/20 pass: 5,645; fail: 1; error: 1 Build 2: aarch64/2019/jul/23 pass: 5,644; fail: 3 Build 3: aarch64/2019/jul/25 pass: 5,644; fail: 3 Build 4: aarch64/2019/jul/30 pass: 5,645; fail: 2 Build 5: aarch64/2019/aug/01 pass: 5,646; fail: 1 Build 6: aarch64/2019/aug/03 pass: 5,646; fail: 1 Build 7: aarch64/2019/aug/06 pass: 5,645; fail: 2 Build 8: aarch64/2019/aug/08 pass: 5,646; fail: 1 Build 9: aarch64/2019/aug/10 pass: 5,646; fail: 1 Build 10: aarch64/2019/nov/12 pass: 5,652 Build 11: aarch64/2019/nov/14 pass: 5,650; fail: 2 Build 12: aarch64/2019/nov/16 pass: 5,652 Build 13: aarch64/2019/dec/03 pass: 5,651; fail: 1 Build 14: aarch64/2019/dec/14 pass: 5,652 ------------------------------------------------------------------------------- release/jdk ------------------------------------------------------------------------------- Build 0: aarch64/2019/jul/18 pass: 8,618; fail: 527; error: 26 Build 1: aarch64/2019/jul/20 pass: 8,619; fail: 519; error: 33 Build 2: aarch64/2019/jul/23 pass: 8,616; fail: 525; error: 30 Build 3: aarch64/2019/jul/25 pass: 8,620; fail: 528; error: 23 Build 4: aarch64/2019/jul/30 pass: 8,610; fail: 529; error: 32 Build 5: aarch64/2019/aug/01 pass: 8,620; fail: 527; error: 24 Build 6: aarch64/2019/aug/03 pass: 8,596; fail: 552; error: 23 Build 7: aarch64/2019/aug/06 pass: 8,616; fail: 528; error: 27 Build 8: aarch64/2019/aug/08 pass: 8,649; fail: 504; error: 18 Build 9: aarch64/2019/aug/10 pass: 8,647; fail: 507; error: 17 Build 10: aarch64/2019/nov/12 pass: 8,650; fail: 513; error: 16 Build 11: aarch64/2019/nov/14 pass: 8,651; fail: 511; error: 17 Build 12: aarch64/2019/nov/16 pass: 8,663; fail: 500; error: 17 Build 13: aarch64/2019/dec/03 pass: 8,671; fail: 493; error: 18 Build 14: aarch64/2019/dec/14 pass: 8,653; fail: 516; error: 14 6 fatal errors were detected; please follow the link above for more detail. ------------------------------------------------------------------------------- release/langtools ------------------------------------------------------------------------------- Build 0: aarch64/2019/jul/18 pass: 3,964 Build 1: aarch64/2019/jul/20 pass: 3,964 Build 2: aarch64/2019/jul/23 pass: 3,964 Build 3: aarch64/2019/jul/25 pass: 3,964 Build 4: aarch64/2019/jul/30 pass: 3,964 Build 5: aarch64/2019/aug/01 pass: 3,964 Build 6: aarch64/2019/aug/03 pass: 3,964 Build 7: aarch64/2019/aug/06 pass: 3,964 Build 8: aarch64/2019/aug/08 pass: 3,964 Build 9: aarch64/2019/aug/10 pass: 3,964 Build 10: aarch64/2019/nov/12 pass: 3,964 Build 11: aarch64/2019/nov/14 pass: 3,964 Build 12: aarch64/2019/nov/16 pass: 3,964 Build 13: aarch64/2019/dec/03 pass: 3,964 Build 14: aarch64/2019/dec/14 pass: 3,964 Previous results can be found here: http://openjdk.linaro.org/jdk13/openjdk-jtreg-nightly-tests/index.html SPECjbb2015 composite regression test completed =============================================== This test measures the relative performance of the server compiler running the SPECjbb2015 composite tests and compares the performance against the baseline performance of the server compiler taken on 2016-11-21. In accordance with [1], the SPECjbb2015 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): 7.66x Relative performance: Server critical-jOPS (nc): 8.71x Details of the test setup and historical results may be found here: http://openjdk.linaro.org/jdk13/SPECjbb2015-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 server compiler on 2014-04-01. Relative performance: Zero: 1.0, Server: 210.67 Server 210.67 / Server 2014-04-01 (71.00): 2.97x Details of the test setup and historical results may be found here: http://openjdk.linaro.org/jdk13/hadoop-terasort-benchmark-results/ This is a summary of the jcstress test results ============================================== The build and test results are cycled every 15 days. 2019-07-19 pass rate: 10488/10488, results: http://openjdk.linaro.org/jdk13/jcstress-nightly-runs/2019/199/results/ 2019-07-21 pass rate: 10487/10488, results: http://openjdk.linaro.org/jdk13/jcstress-nightly-runs/2019/201/results/ 2019-07-24 pass rate: 10488/10488, results: http://openjdk.linaro.org/jdk13/jcstress-nightly-runs/2019/204/results/ 2019-07-26 pass rate: 10487/10488, results: http://openjdk.linaro.org/jdk13/jcstress-nightly-runs/2019/206/results/ 2019-07-31 pass rate: 10488/10488, results: http://openjdk.linaro.org/jdk13/jcstress-nightly-runs/2019/211/results/ 2019-08-02 pass rate: 10488/10488, results: http://openjdk.linaro.org/jdk13/jcstress-nightly-runs/2019/213/results/ 2019-08-04 pass rate: 10488/10488, results: http://openjdk.linaro.org/jdk13/jcstress-nightly-runs/2019/215/results/ 2019-08-07 pass rate: 10488/10488, results: http://openjdk.linaro.org/jdk13/jcstress-nightly-runs/2019/218/results/ 2019-08-09 pass rate: 10487/10488, results: http://openjdk.linaro.org/jdk13/jcstress-nightly-runs/2019/220/results/ 2019-08-11 pass rate: 10487/10488, results: http://openjdk.linaro.org/jdk13/jcstress-nightly-runs/2019/222/results/ 2019-11-12 pass rate: 10490/10490, results: http://openjdk.linaro.org/jdk13/jcstress-nightly-runs/2019/316/results/ 2019-11-15 pass rate: 10490/10490, results: http://openjdk.linaro.org/jdk13/jcstress-nightly-runs/2019/318/results/ 2019-11-17 pass rate: 10490/10490, results: http://openjdk.linaro.org/jdk13/jcstress-nightly-runs/2019/320/results/ 2019-12-04 pass rate: 10490/10490, results: http://openjdk.linaro.org/jdk13/jcstress-nightly-runs/2019/337/results/ 2019-12-15 pass rate: 10490/10490, results: http://openjdk.linaro.org/jdk13/jcstress-nightly-runs/2019/348/results/ For detailed information on the test output please refer to: http://openjdk.linaro.org/jdk13/jcstress-nightly-runs/ From ci_notify at linaro.org Mon Dec 16 00:02:00 2019 From: ci_notify at linaro.org (ci_notify at linaro.org) Date: Mon, 16 Dec 2019 00:02:00 +0000 (UTC) Subject: [aarch64-port-dev ] JTREG, JCStress, SPECjbb2015 and Hadoop/Terasort results for OpenJDK 11u on AArch64 Message-ID: <488307686.4929.1576454521554.JavaMail.javamailuser@localhost> This is a summary of the JTREG test results =========================================== The build and test results are cycled every 15 days. For detailed information on the test output please refer to: http://openjdk.linaro.org/jdk11u/openjdk-jtreg-nightly-tests/summary/2019/348/summary.html ------------------------------------------------------------------------------- release/hotspot ------------------------------------------------------------------------------- Build 0: aarch64/2019/aug/22 pass: 5,755; fail: 4 Build 1: aarch64/2019/sep/04 pass: 5,764; fail: 2 Build 2: aarch64/2019/sep/05 pass: 5,764; fail: 2 Build 3: aarch64/2019/sep/10 pass: 5,764; fail: 2 Build 4: aarch64/2019/sep/17 pass: 5,763; fail: 3 Build 5: aarch64/2019/sep/21 pass: 5,764; fail: 2 Build 6: aarch64/2019/oct/04 pass: 5,764; fail: 2 Build 7: aarch64/2019/oct/17 pass: 5,764; fail: 2 Build 8: aarch64/2019/oct/31 pass: 5,784; fail: 1 Build 9: aarch64/2019/nov/09 pass: 5,773; fail: 3 Build 10: aarch64/2019/nov/16 pass: 5,775; fail: 1 Build 11: aarch64/2019/nov/21 pass: 5,775; fail: 1 Build 12: aarch64/2019/dec/05 pass: 5,775; fail: 1 Build 13: aarch64/2019/dec/08 pass: 5,775; fail: 1 Build 14: aarch64/2019/dec/14 pass: 5,775; fail: 1 ------------------------------------------------------------------------------- release/jdk ------------------------------------------------------------------------------- Build 0: aarch64/2019/aug/22 pass: 8,446; fail: 494; error: 15 Build 1: aarch64/2019/sep/04 pass: 8,483; fail: 465; error: 10 Build 2: aarch64/2019/sep/05 pass: 8,465; fail: 479; error: 14 Build 3: aarch64/2019/sep/10 pass: 8,444; fail: 500; error: 14 Build 4: aarch64/2019/sep/17 pass: 8,462; fail: 482; error: 12 Build 5: aarch64/2019/sep/21 pass: 8,467; fail: 478; error: 13 Build 6: aarch64/2019/oct/04 pass: 8,444; fail: 498; error: 16 Build 7: aarch64/2019/oct/17 pass: 8,452; fail: 493; error: 16 Build 8: aarch64/2019/oct/31 pass: 8,468; fail: 490; error: 14 Build 9: aarch64/2019/nov/09 pass: 8,487; fail: 470; error: 16 Build 10: aarch64/2019/nov/16 pass: 8,475; fail: 484; error: 15 Build 11: aarch64/2019/nov/21 pass: 8,489; fail: 497; error: 13 Build 12: aarch64/2019/dec/05 pass: 8,492; fail: 501; error: 11 Build 13: aarch64/2019/dec/08 pass: 8,482; fail: 505; error: 17 Build 14: aarch64/2019/dec/14 pass: 8,512; fail: 481; error: 12 3 fatal errors were detected; please follow the link above for more detail. ------------------------------------------------------------------------------- release/langtools ------------------------------------------------------------------------------- Build 0: aarch64/2019/aug/22 pass: 3,909 Build 1: aarch64/2019/sep/04 pass: 3,910 Build 2: aarch64/2019/sep/05 pass: 3,910 Build 3: aarch64/2019/sep/10 pass: 3,910 Build 4: aarch64/2019/sep/17 pass: 3,910 Build 5: aarch64/2019/sep/21 pass: 3,910 Build 6: aarch64/2019/oct/04 pass: 3,910 Build 7: aarch64/2019/oct/17 pass: 3,910 Build 8: aarch64/2019/oct/31 pass: 3,910 Build 9: aarch64/2019/nov/09 pass: 3,910 Build 10: aarch64/2019/nov/16 pass: 3,910 Build 11: aarch64/2019/nov/21 pass: 3,910 Build 12: aarch64/2019/dec/05 pass: 3,910 Build 13: aarch64/2019/dec/08 pass: 3,910 Build 14: aarch64/2019/dec/14 pass: 3,910 Previous results can be found here: http://openjdk.linaro.org/jdk11u/openjdk-jtreg-nightly-tests/index.html SPECjbb2015 composite regression test completed =============================================== This test measures the relative performance of the server compiler running the SPECjbb2015 composite tests and compares the performance against the baseline performance of the server compiler taken on 2016-11-21. In accordance with [1], the SPECjbb2015 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): 7.46x Relative performance: Server critical-jOPS (nc): 7.85x Details of the test setup and historical results may be found here: http://openjdk.linaro.org/jdk11u/SPECjbb2015-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 server compiler on 2014-04-01. Relative performance: Zero: 1.0, Server: 210.67 Server 210.67 / Server 2014-04-01 (71.00): 2.97x Details of the test setup and historical results may be found here: http://openjdk.linaro.org/jdk11u/hadoop-terasort-benchmark-results/ This is a summary of the jcstress test results ============================================== The build and test results are cycled every 15 days. 2019-08-23 pass rate: 10489/10489, results: http://openjdk.linaro.org/jdk11u/jcstress-nightly-runs/2019/234/results/ 2019-09-05 pass rate: 10489/10489, results: http://openjdk.linaro.org/jdk11u/jcstress-nightly-runs/2019/247/results/ 2019-09-07 pass rate: 10489/10489, results: http://openjdk.linaro.org/jdk11u/jcstress-nightly-runs/2019/248/results/ 2019-09-11 pass rate: 10489/10489, results: http://openjdk.linaro.org/jdk11u/jcstress-nightly-runs/2019/253/results/ 2019-09-18 pass rate: 10489/10489, results: http://openjdk.linaro.org/jdk11u/jcstress-nightly-runs/2019/260/results/ 2019-09-22 pass rate: 10489/10489, results: http://openjdk.linaro.org/jdk11u/jcstress-nightly-runs/2019/264/results/ 2019-10-05 pass rate: 10489/10489, results: http://openjdk.linaro.org/jdk11u/jcstress-nightly-runs/2019/277/results/ 2019-10-18 pass rate: 10489/10489, results: http://openjdk.linaro.org/jdk11u/jcstress-nightly-runs/2019/290/results/ 2019-11-01 pass rate: 10489/10489, results: http://openjdk.linaro.org/jdk11u/jcstress-nightly-runs/2019/304/results/ 2019-11-10 pass rate: 10490/10490, results: http://openjdk.linaro.org/jdk11u/jcstress-nightly-runs/2019/313/results/ 2019-11-17 pass rate: 10490/10490, results: http://openjdk.linaro.org/jdk11u/jcstress-nightly-runs/2019/320/results/ 2019-11-22 pass rate: 10490/10490, results: http://openjdk.linaro.org/jdk11u/jcstress-nightly-runs/2019/325/results/ 2019-12-07 pass rate: 10490/10490, results: http://openjdk.linaro.org/jdk11u/jcstress-nightly-runs/2019/339/results/ 2019-12-09 pass rate: 10490/10490, results: http://openjdk.linaro.org/jdk11u/jcstress-nightly-runs/2019/342/results/ 2019-12-15 pass rate: 10490/10490, results: http://openjdk.linaro.org/jdk11u/jcstress-nightly-runs/2019/348/results/ For detailed information on the test output please refer to: http://openjdk.linaro.org/jdk11u/jcstress-nightly-runs/ From gnu.andrew at redhat.com Mon Dec 16 02:38:24 2019 From: gnu.andrew at redhat.com (gnu.andrew at redhat.com) Date: Mon, 16 Dec 2019 02:38:24 +0000 Subject: [aarch64-port-dev ] hg: aarch64-port/jdk8u-shenandoah/jdk: 11 new changesets Message-ID: <201912160238.xBG2cPYa002513@aojmv0008.oracle.com> Changeset: dd10fb830ea9 Author: andrew Date: 2019-10-15 21:37 +0100 URL: https://hg.openjdk.java.net/aarch64-port/jdk8u-shenandoah/jdk/rev/dd10fb830ea9 Added tag jdk8u232-ga for changeset 5456f24496f4 ! .hgtags Changeset: 1560848c85d1 Author: andrew Date: 2019-09-06 03:21 +0100 URL: https://hg.openjdk.java.net/aarch64-port/jdk8u-shenandoah/jdk/rev/1560848c85d1 Added tag jdk8u242-b00 for changeset 1e8cdf311133 ! .hgtags Changeset: c382b2cf5259 Author: aivanov Date: 2019-08-18 21:36 +0100 URL: https://hg.openjdk.java.net/aarch64-port/jdk8u-shenandoah/jdk/rev/c382b2cf5259 8222108: Reduce minRefreshTime for updating remote printer list on Windows Reviewed-by: prr, serb ! src/windows/classes/sun/print/PrintServiceLookupProvider.java ! test/jdk/java/awt/print/RemotePrinterStatusRefresh/RemotePrinterStatusRefresh.java Changeset: 129d5c5426db Author: serb Date: 2019-06-12 13:50 -0700 URL: https://hg.openjdk.java.net/aarch64-port/jdk8u-shenandoah/jdk/rev/129d5c5426db 8217676: Upgrade libpng to 1.6.37 Reviewed-by: prr, jdv, kcr ! THIRD_PARTY_README ! make/lib/Awt2dLibraries.gmk ! src/share/native/sun/awt/libpng/CHANGES ! src/share/native/sun/awt/libpng/LICENSE ! src/share/native/sun/awt/libpng/README ! src/share/native/sun/awt/libpng/png.c ! src/share/native/sun/awt/libpng/png.h ! src/share/native/sun/awt/libpng/pngconf.h ! src/share/native/sun/awt/libpng/pngdebug.h ! src/share/native/sun/awt/libpng/pngerror.c ! src/share/native/sun/awt/libpng/pngget.c ! src/share/native/sun/awt/libpng/pnginfo.h ! src/share/native/sun/awt/libpng/pnglibconf.h ! src/share/native/sun/awt/libpng/pngmem.c ! src/share/native/sun/awt/libpng/pngpread.c ! src/share/native/sun/awt/libpng/pngpriv.h ! src/share/native/sun/awt/libpng/pngread.c ! src/share/native/sun/awt/libpng/pngrio.c ! src/share/native/sun/awt/libpng/pngrtran.c ! src/share/native/sun/awt/libpng/pngrutil.c ! src/share/native/sun/awt/libpng/pngset.c ! src/share/native/sun/awt/libpng/pngstruct.h ! src/share/native/sun/awt/libpng/pngtrans.c Changeset: f4b5ec44caab Author: ptbrunet Date: 2015-07-24 13:58 -0500 URL: https://hg.openjdk.java.net/aarch64-port/jdk8u-shenandoah/jdk/rev/f4b5ec44caab 8077707: jdk9 b58 cannot run any graphical application on Win 8 with JAWS running Summary: change dialog proc wparam type from UINT to WPARAM, lparam type from LONG to LPARAM Reviewed-by: serb, alexsch, van Contributed-by: peter.brunet at oracle.com ! src/windows/native/sun/bridge/JavaAccessBridge.cpp ! src/windows/native/sun/bridge/JavaAccessBridge.h Changeset: 0fc878b99541 Author: ptbrunet Date: 2015-08-03 15:48 -0500 URL: https://hg.openjdk.java.net/aarch64-port/jdk8u-shenandoah/jdk/rev/0fc878b99541 8132249: Clean up JAB debugging code Summary: remove dead code; replace DEBUG_CODE with PrintDebugString; fix typos, incorrect print args Reviewed-by: van Contributed-by: peter.brunet at oracle.com ! src/windows/native/sun/bridge/AccessBridgeATInstance.cpp ! src/windows/native/sun/bridge/AccessBridgeJavaEntryPoints.cpp ! src/windows/native/sun/bridge/AccessBridgeJavaVMInstance.cpp ! src/windows/native/sun/bridge/AccessBridgeWindowsEntryPoints.cpp ! src/windows/native/sun/bridge/JavaAccessBridge.cpp ! src/windows/native/sun/bridge/WinAccessBridge.cpp Changeset: e5867c8ddb03 Author: andrew Date: 2019-10-17 13:48 +0100 URL: https://hg.openjdk.java.net/aarch64-port/jdk8u-shenandoah/jdk/rev/e5867c8ddb03 Merge ! .hgtags Changeset: d32fc856e071 Author: prr Date: 2019-10-31 14:22 +0100 URL: https://hg.openjdk.java.net/aarch64-port/jdk8u-shenandoah/jdk/rev/d32fc856e071 8212071: Need to set the FreeType LCD Filter to reduce fringing. Reviewed-by: prr, lbourges Contributed-by: John Neffenger ! src/share/native/sun/font/freetypeScaler.c Changeset: 8ec1d42a9bad Author: andrew Date: 2019-11-08 16:49 +0000 URL: https://hg.openjdk.java.net/aarch64-port/jdk8u-shenandoah/jdk/rev/8ec1d42a9bad Added tag jdk8u242-b01 for changeset d32fc856e071 ! .hgtags Changeset: e3411752cc68 Author: andrew Date: 2019-11-08 18:16 +0000 URL: https://hg.openjdk.java.net/aarch64-port/jdk8u-shenandoah/jdk/rev/e3411752cc68 Merge jdk8u242-b01 ! .hgtags ! src/share/native/sun/font/freetypeScaler.c Changeset: 0ac6a154bbbf Author: andrew Date: 2019-11-08 18:16 +0000 URL: https://hg.openjdk.java.net/aarch64-port/jdk8u-shenandoah/jdk/rev/0ac6a154bbbf Added tag aarch64-shenandoah-jdk8u242-b01 for changeset e3411752cc68 ! .hgtags From gnu.andrew at redhat.com Mon Dec 16 02:38:53 2019 From: gnu.andrew at redhat.com (gnu.andrew at redhat.com) Date: Mon, 16 Dec 2019 02:38:53 +0000 Subject: [aarch64-port-dev ] hg: aarch64-port/jdk8u-shenandoah/langtools: 9 new changesets Message-ID: <201912160238.xBG2cs8i002698@aojmv0008.oracle.com> Changeset: bb183e5fa58f Author: andrew Date: 2019-10-15 21:37 +0100 URL: https://hg.openjdk.java.net/aarch64-port/jdk8u-shenandoah/langtools/rev/bb183e5fa58f Added tag jdk8u232-ga for changeset 735048c9f2d6 ! .hgtags Changeset: 4b5336d558e8 Author: andrew Date: 2019-09-06 03:21 +0100 URL: https://hg.openjdk.java.net/aarch64-port/jdk8u-shenandoah/langtools/rev/4b5336d558e8 Added tag jdk8u242-b00 for changeset 2338eb5fa755 ! .hgtags Changeset: f02d967ddce2 Author: mcimadamore Date: 2015-01-09 15:50 +0000 URL: https://hg.openjdk.java.net/aarch64-port/jdk8u-shenandoah/langtools/rev/f02d967ddce2 8067429: java.lang.VerifyError: Inconsistent stackmap frames at branch target Summary: bitset for alive variables contains info about variables out of range Reviewed-by: mcimadamore Contributed-by: srikanth.adayapalam at oracle.com ! src/share/classes/com/sun/tools/javac/jvm/Gen.java + test/tools/javac/BranchToFewerDefines.java Changeset: 9e6bb52ba514 Author: zgu Date: 2019-09-12 15:22 -0400 URL: https://hg.openjdk.java.net/aarch64-port/jdk8u-shenandoah/langtools/rev/9e6bb52ba514 8217676: Upgrade libpng to 1.6.37 Reviewed-by: prr, jdv, kcr ! THIRD_PARTY_README Changeset: 97341f0e0326 Author: andrew Date: 2019-09-16 14:55 +0100 URL: https://hg.openjdk.java.net/aarch64-port/jdk8u-shenandoah/langtools/rev/97341f0e0326 Merge Changeset: 92a07f0a1bb1 Author: andrew Date: 2019-10-17 13:47 +0100 URL: https://hg.openjdk.java.net/aarch64-port/jdk8u-shenandoah/langtools/rev/92a07f0a1bb1 Merge ! .hgtags Changeset: 5b0a0cf41fc1 Author: andrew Date: 2019-11-08 16:49 +0000 URL: https://hg.openjdk.java.net/aarch64-port/jdk8u-shenandoah/langtools/rev/5b0a0cf41fc1 Added tag jdk8u242-b01 for changeset 92a07f0a1bb1 ! .hgtags Changeset: 5eaefde2a14c Author: andrew Date: 2019-11-08 18:16 +0000 URL: https://hg.openjdk.java.net/aarch64-port/jdk8u-shenandoah/langtools/rev/5eaefde2a14c Merge jdk8u242-b01 ! .hgtags Changeset: d1aa580b0f3e Author: andrew Date: 2019-11-08 18:16 +0000 URL: https://hg.openjdk.java.net/aarch64-port/jdk8u-shenandoah/langtools/rev/d1aa580b0f3e Added tag aarch64-shenandoah-jdk8u242-b01 for changeset 5eaefde2a14c ! .hgtags From gnu.andrew at redhat.com Mon Dec 16 02:39:43 2019 From: gnu.andrew at redhat.com (gnu.andrew at redhat.com) Date: Mon, 16 Dec 2019 02:39:43 +0000 Subject: [aarch64-port-dev ] hg: aarch64-port/jdk8u-shenandoah/nashorn: 7 new changesets Message-ID: <201912160239.xBG2dhD1003801@aojmv0008.oracle.com> Changeset: 0e89f4ee1f28 Author: andrew Date: 2019-10-15 21:37 +0100 URL: https://hg.openjdk.java.net/aarch64-port/jdk8u-shenandoah/nashorn/rev/0e89f4ee1f28 Added tag jdk8u232-ga for changeset fba077f48da2 ! .hgtags Changeset: ad8af81cc28b Author: andrew Date: 2019-09-06 03:21 +0100 URL: https://hg.openjdk.java.net/aarch64-port/jdk8u-shenandoah/nashorn/rev/ad8af81cc28b Added tag jdk8u242-b00 for changeset 8a951fd037e2 ! .hgtags Changeset: 09109e8d8cfd Author: zgu Date: 2019-09-12 15:23 -0400 URL: https://hg.openjdk.java.net/aarch64-port/jdk8u-shenandoah/nashorn/rev/09109e8d8cfd 8217676: Upgrade libpng to 1.6.37 Reviewed-by: prr, jdv, kcr ! THIRD_PARTY_README Changeset: 6c540cfd2593 Author: andrew Date: 2019-10-17 13:49 +0100 URL: https://hg.openjdk.java.net/aarch64-port/jdk8u-shenandoah/nashorn/rev/6c540cfd2593 Merge ! .hgtags Changeset: 49b31f261653 Author: andrew Date: 2019-11-08 16:49 +0000 URL: https://hg.openjdk.java.net/aarch64-port/jdk8u-shenandoah/nashorn/rev/49b31f261653 Added tag jdk8u242-b01 for changeset 6c540cfd2593 ! .hgtags Changeset: 6874db54bce3 Author: andrew Date: 2019-11-08 18:16 +0000 URL: https://hg.openjdk.java.net/aarch64-port/jdk8u-shenandoah/nashorn/rev/6874db54bce3 Merge jdk8u242-b01 ! .hgtags Changeset: 44e925ae5526 Author: andrew Date: 2019-11-08 18:16 +0000 URL: https://hg.openjdk.java.net/aarch64-port/jdk8u-shenandoah/nashorn/rev/44e925ae5526 Added tag aarch64-shenandoah-jdk8u242-b01 for changeset 6874db54bce3 ! .hgtags From gnu.andrew at redhat.com Mon Dec 16 03:34:58 2019 From: gnu.andrew at redhat.com (gnu.andrew at redhat.com) Date: Mon, 16 Dec 2019 03:34:58 +0000 Subject: [aarch64-port-dev ] hg: aarch64-port/jdk8u-shenandoah/hotspot: 17 new changesets Message-ID: <201912160334.xBG3YxKi002970@aojmv0008.oracle.com> Changeset: b44df6c5942c Author: andrew Date: 2019-10-15 21:37 +0100 URL: https://hg.openjdk.java.net/aarch64-port/jdk8u-shenandoah/hotspot/rev/b44df6c5942c Added tag jdk8u232-ga for changeset 12177d88b89c ! .hgtags Changeset: 3e0c18feb006 Author: andrew Date: 2019-09-06 03:21 +0100 URL: https://hg.openjdk.java.net/aarch64-port/jdk8u-shenandoah/hotspot/rev/3e0c18feb006 Added tag jdk8u242-b00 for changeset 760b28d87178 ! .hgtags Changeset: cb028a891ac9 Author: zgu Date: 2019-09-12 15:15 -0400 URL: https://hg.openjdk.java.net/aarch64-port/jdk8u-shenandoah/hotspot/rev/cb028a891ac9 8178870: instrumentation.retransformClasses cause coredump Summary: Don't double-free cached class bytes on redefinition loading failure. Reviewed-by: sspitsyn, jiangli ! src/share/vm/prims/jvmtiRedefineClasses.cpp + test/runtime/RedefineTests/RedefineDoubleDelete.java + test/runtime/RedefineTests/libRedefineDoubleDelete.c + test/runtime/RedefineTests/test8178870.sh Changeset: 7f237efc2d2a Author: zgu Date: 2019-09-12 15:29 -0400 URL: https://hg.openjdk.java.net/aarch64-port/jdk8u-shenandoah/hotspot/rev/7f237efc2d2a 8217676: Upgrade libpng to 1.6.37 Reviewed-by: prr, jdv, kcr ! THIRD_PARTY_README Changeset: eaae2ae06faf Author: adlertz Date: 2014-02-26 07:46 +0100 URL: https://hg.openjdk.java.net/aarch64-port/jdk8u-shenandoah/hotspot/rev/eaae2ae06faf 8010500: [parfait] Possible null pointer dereference at hotspot/src/share/vm/opto/loopnode.hpp Summary: Added NULL check for loopnode() in get_pre_loop_end() Reviewed-by: kvn, roland ! src/share/vm/opto/superword.cpp Changeset: 13ba54363544 Author: shade Date: 2019-09-16 12:02 +0200 URL: https://hg.openjdk.java.net/aarch64-port/jdk8u-shenandoah/hotspot/rev/13ba54363544 8230238: Add another regression test for JDK-8134739 Reviewed-by: kvn + test/compiler/loopopts/superword/TestFuzzPreLoop.java Changeset: 7d5c800dae75 Author: shade Date: 2019-09-10 19:58 +0200 URL: https://hg.openjdk.java.net/aarch64-port/jdk8u-shenandoah/hotspot/rev/7d5c800dae75 8230813: Add JDK-8010500 to compiler/loopopts/superword/TestFuzzPreLoop.java bug list Reviewed-by: zgu ! test/compiler/loopopts/superword/TestFuzzPreLoop.java Changeset: 2695509c59f8 Author: andrew Date: 2019-10-17 13:48 +0100 URL: https://hg.openjdk.java.net/aarch64-port/jdk8u-shenandoah/hotspot/rev/2695509c59f8 Merge ! .hgtags Changeset: eee5798e1b28 Author: fyang Date: 2019-10-28 13:29 +0800 URL: https://hg.openjdk.java.net/aarch64-port/jdk8u-shenandoah/hotspot/rev/eee5798e1b28 8231988: Unexpected test result caused by C2 IdealLoopTree::do_remove_empty_loop Summary: Duplicate cmp node in empty loop if it has other users Reviewed-by: neliasso, thartmann Contributed-by: wanghuang3 at huawei.com, xietuo at huawei.com ! src/share/vm/opto/loopTransform.cpp + test/compiler/loopopts/TestRemoveEmptyLoop.java Changeset: dc471edac21e Author: shade Date: 2019-10-31 19:36 +0100 URL: https://hg.openjdk.java.net/aarch64-port/jdk8u-shenandoah/hotspot/rev/dc471edac21e 8231398: Add time tracing for gc log rotation at safepoint cleanup Reviewed-by: phh, andrew ! src/share/vm/runtime/safepoint.cpp Changeset: 4a7da2a46cb1 Author: coleenp Date: 2015-08-20 11:18 -0400 URL: https://hg.openjdk.java.net/aarch64-port/jdk8u-shenandoah/hotspot/rev/4a7da2a46cb1 8133951: Zero interpreter asserts in stubRoutines.cpp Summary: Allow zero sized code buffer when checking if there's enough remaining size Reviewed-by: kvn ! src/share/vm/runtime/stubRoutines.cpp Changeset: 9b865b281711 Author: fzhinkin Date: 2015-02-27 11:41 +0300 URL: https://hg.openjdk.java.net/aarch64-port/jdk8u-shenandoah/hotspot/rev/9b865b281711 8073154: NULL-pointer dereferencing in LIR_OpProfileType::print_instr Reviewed-by: iveresov ! src/share/vm/c1/c1_LIR.cpp + test/compiler/print/TestProfileReturnTypePrinting.java Changeset: ce42ae95d4d6 Author: thartmann Date: 2019-10-08 15:38 +0200 URL: https://hg.openjdk.java.net/aarch64-port/jdk8u-shenandoah/hotspot/rev/ce42ae95d4d6 8134739: compiler/loopopts/superword/TestVectorizationWithInvariant crashes in loop opts Summary: Bail out of superword optimization if loop was removed (i.e., if zero-trip Opaque1Node was removed). Reviewed-by: kvn, roland ! src/share/vm/opto/loopnode.hpp ! src/share/vm/opto/superword.cpp Changeset: ed8892ef0a8d Author: andrew Date: 2019-11-08 16:49 +0000 URL: https://hg.openjdk.java.net/aarch64-port/jdk8u-shenandoah/hotspot/rev/ed8892ef0a8d Added tag jdk8u242-b01 for changeset ce42ae95d4d6 ! .hgtags Changeset: e4c7daab7059 Author: andrew Date: 2019-11-27 05:20 +0000 URL: https://hg.openjdk.java.net/aarch64-port/jdk8u-shenandoah/hotspot/rev/e4c7daab7059 Merge jdk8u242-b01 ! .hgtags ! src/share/vm/c1/c1_LIR.cpp ! src/share/vm/opto/loopTransform.cpp ! src/share/vm/opto/loopnode.hpp ! src/share/vm/opto/superword.cpp ! src/share/vm/runtime/safepoint.cpp ! src/share/vm/runtime/stubRoutines.cpp Changeset: fdaa53e7d0e5 Author: andrew Date: 2019-11-27 05:20 +0000 URL: https://hg.openjdk.java.net/aarch64-port/jdk8u-shenandoah/hotspot/rev/fdaa53e7d0e5 Added tag aarch64-shenandoah-jdk8u242-b01 for changeset e4c7daab7059 ! .hgtags Changeset: 85a664ef768d Author: andrew Date: 2019-12-16 02:46 +0000 URL: https://hg.openjdk.java.net/aarch64-port/jdk8u-shenandoah/hotspot/rev/85a664ef768d Merge - src/cpu/aarch64/vm/shenandoahBarrierSet_aarch64.cpp - src/cpu/ppc/vm/shenandoahBarrierSet_ppc.cpp - src/cpu/sparc/vm/shenandoahBarrierSet_sparc.cpp - src/cpu/x86/vm/shenandoahBarrierSet_x86.cpp - src/cpu/zero/vm/shenandoahBarrierSet_zero.cpp ! src/share/vm/c1/c1_LIR.cpp - src/share/vm/gc_implementation/shenandoah/shenandoahBrooksPointer.hpp - src/share/vm/gc_implementation/shenandoah/shenandoahBrooksPointer.inline.hpp - src/share/vm/gc_implementation/shenandoah/shenandoahHeapLock.hpp ! src/share/vm/opto/loopTransform.cpp ! src/share/vm/opto/loopnode.hpp - src/share/vm/opto/shenandoahSupport.cpp - src/share/vm/opto/shenandoahSupport.hpp ! src/share/vm/runtime/stubRoutines.cpp From felix.yang at huawei.com Mon Dec 16 03:43:34 2019 From: felix.yang at huawei.com (Yangfei (Felix)) Date: Mon, 16 Dec 2019 03:43:34 +0000 Subject: [aarch64-port-dev ] RFR 8135018: AARCH64: Missing memory barriers for CMS collector In-Reply-To: <9cb488f4-a534-bc63-961f-6e676dd7b409@redhat.com> References: <2b433414-fab1-c63d-1e07-76ddd4abe298@redhat.com> <42729c1e-f90a-2a8d-cd48-c50e7a160245@redhat.com> <9cb488f4-a534-bc63-961f-6e676dd7b409@redhat.com> Message-ID: Hi Liu Xin, Thanks for finding this. Looks like the new backport patch still mixed code changes from JDK-8076987. Does that brings any side-effect? Normally, I prefer backporting JDK-8076987 & JDK-8078438 to jdk8u-dev first. Then, they will be merged to jdk8u-shenandoah after some time. After that, we can do a clean backport of JDK-8076987 for jdk8u-shenandoah. I always try to go this way when my backport patch changed shared code. It should help reduce the complexity for merging from jdk8u-dev to jdk8u-shenandoah. Felix > -----Original Message----- > From: aarch64-port-dev [mailto:aarch64-port-dev-bounces at openjdk.java.net] > On Behalf Of Andrew Haley > Sent: Sunday, December 15, 2019 6:18 AM > To: Liu Xin > Cc: Doerr, Martin ; > aarch64-port-dev at openjdk.java.net > Subject: Re: [aarch64-port-dev ] RFR 8135018: AARCH64: Missing memory > barriers for CMS collector > > On 12/14/19 4:47 AM, Liu Xin wrote: > > I trace the feature UseCondCardMark. It was introduced by the > > following changes. > > https://bugs.openjdk.java.net/browse/JDK-8076987 C1 > > https://bugs.openjdk.java.net/browse/JDK-8078438 interpreter > > UseCondCardMark is only supported by C2 currently. Yes, my original > > patch does miss hunk -- the x86 part. That's why I propose a new webrev > here. > > It's almost a clean backport for JDK-8135018. Let's solve the missing > > barrier bug first. Could you take a look at it? > > https://cr.openjdk.java.net/~xliu/8135018/01/webrev/ > > That's OK, thanks. > > -- > Andrew Haley (he/him) > Java Platform Lead Engineer > Red Hat UK Ltd. https://keybase.io/andrewhaley > EAC8 43EB D3EF DB98 CC77 2FAD A5CD 6035 332F A671 From aph at redhat.com Mon Dec 16 08:59:51 2019 From: aph at redhat.com (Andrew Haley) Date: Mon, 16 Dec 2019 08:59:51 +0000 Subject: [aarch64-port-dev ] RFR 8135018: AARCH64: Missing memory barriers for CMS collector In-Reply-To: References: <2b433414-fab1-c63d-1e07-76ddd4abe298@redhat.com> <42729c1e-f90a-2a8d-cd48-c50e7a160245@redhat.com> Message-ID: <2e483546-f34f-3c96-a2aa-6d7b4fc47cc2@redhat.com> On 12/14/19 4:47 AM, Liu Xin wrote: > I trace the feature UseCondCardMark. It was > introduced by the following changes. > https://bugs.openjdk.java.net/browse/JDK-8076987 C1 > https://bugs.openjdk.java.net/browse/JDK-8078438 interpreter > UseCondCardMark is only supported by C2 currently. UseCondCardMark was supposed to be a performance enhancement for very large multi-core systems, but we realized that it needed a StoreLoad barrier. Because StoreLoad is so expensive there is no performance advantage, therefore as far as I can see the whole UseCondCardMark exercise is a waste of time. There is no point back-porting changes to the interpreter and C1. Unless someone does some performance measurements to prove that there is some performance gain in C1 and the interpreter, UseCondCardMark changes should not be back-ported. -- Andrew Haley (he/him) Java Platform Lead Engineer Red Hat UK Ltd. https://keybase.io/andrewhaley EAC8 43EB D3EF DB98 CC77 2FAD A5CD 6035 332F A671 From martin.doerr at sap.com Mon Dec 16 10:28:25 2019 From: martin.doerr at sap.com (Doerr, Martin) Date: Mon, 16 Dec 2019 10:28:25 +0000 Subject: [aarch64-port-dev ] RFR 8135018: AARCH64: Missing memory barriers for CMS collector In-Reply-To: References: <2b433414-fab1-c63d-1e07-76ddd4abe298@redhat.com> <42729c1e-f90a-2a8d-cd48-c50e7a160245@redhat.com> <2e483546-f34f-3c96-a2aa-6d7b4fc47cc2@redhat.com> Message-ID: Hi Ix, I would only recommend pushing your new webrev if it?s clear that JDK-8078438 will never get backported. Otherwise, the membar in MacroAssembler::store_check will be missing if it doesn?t get added back manually. If we go this way, I suggest to add a comment to JDK-8078438 as reminder. I don?t think performance measurements were needed because the membar is required for correctness. And, as you said, the feature is off by default and I wonder who would ever turn it on. Best regards, Martin From: Liu Xin Sent: Montag, 16. Dezember 2019 10:48 To: Andrew Haley Cc: Doerr, Martin ; aarch64-port-dev at openjdk.java.net; Hohensee, Paul Subject: Re: RFR 8135018: AARCH64: Missing memory barriers for CMS collector Hi, Andrew and Felix, I did backport as Felix suggested. To get UseCondCardMark, we need to backport other 3 patches. hg qseries as follows ( applied in order) 8076987: https://cr.openjdk.java.net/~xliu/8076987/00/webrev/ 8078438: https://cr.openjdk.java.net/~xliu/8078438/00/webrev/ 8079315: https://cr.openjdk.java.net/~xliu/8079315/00/webrev/ 8135018: https://cr.openjdk.java.net/~xliu/8135018/02/webrev/ As Andrew pointed out, I also notice that it introduces a storeLoad membar for interpreter if UseCondCardMark is on. The reason I didn't backport UseCondCardMark at first place because it's off by default. I need to run all tests again with the new parameter -XX:+UseCondCardMark to validate it. Another reason is that all performance evaluation was done on x86_64. It's really time consuming to evaluate performance impact on aarch64. So I shortcut to fix my primary bug. Could you sponsor my previous webrev? https://cr.openjdk.java.net/~xliu/8135018/01/webrev/ It does have a conflict with c1_LIRGenerator.cpp. How about I send another webrev to jdk8u and update it as well? thanks, --lx On Mon, Dec 16, 2019 at 1:00 AM Andrew Haley > wrote: On 12/14/19 4:47 AM, Liu Xin wrote: > I trace the feature UseCondCardMark. It was > introduced by the following changes. > https://bugs.openjdk.java.net/browse/JDK-8076987 C1 > https://bugs.openjdk.java.net/browse/JDK-8078438 interpreter > UseCondCardMark is only supported by C2 currently. UseCondCardMark was supposed to be a performance enhancement for very large multi-core systems, but we realized that it needed a StoreLoad barrier. Because StoreLoad is so expensive there is no performance advantage, therefore as far as I can see the whole UseCondCardMark exercise is a waste of time. There is no point back-porting changes to the interpreter and C1. Unless someone does some performance measurements to prove that there is some performance gain in C1 and the interpreter, UseCondCardMark changes should not be back-ported. -- Andrew Haley (he/him) Java Platform Lead Engineer Red Hat UK Ltd. https://keybase.io/andrewhaley EAC8 43EB D3EF DB98 CC77 2FAD A5CD 6035 332F A671 From rkennke at redhat.com Mon Dec 16 10:46:55 2019 From: rkennke at redhat.com (Roman Kennke) Date: Mon, 16 Dec 2019 11:46:55 +0100 Subject: [aarch64-port-dev ] RFR: Merge late fix from shenandoah/jdk8 Message-ID: <22715056-0ca4-5be6-be98-988e8c7950f1@redhat.com> Hi there, right after I brought in the big Shenandoah merge, a user reported a bug, which is shenandoah/jdk8 specific and which I fixed on Friday. I'd like to include it in the integration repo. It is this fix: http://hg.openjdk.java.net/shenandoah/jdk8/hotspot/rev/353510f8073a It applies and merges cleanly. Testing: it went through our CI several times over the weekend. Roman From felix.yang at huawei.com Mon Dec 16 11:20:56 2019 From: felix.yang at huawei.com (Yangfei (Felix)) Date: Mon, 16 Dec 2019 11:20:56 +0000 Subject: [aarch64-port-dev ] RFR 8135018: AARCH64: Missing memory barriers for CMS collector In-Reply-To: References: <2b433414-fab1-c63d-1e07-76ddd4abe298@redhat.com> <42729c1e-f90a-2a8d-cd48-c50e7a160245@redhat.com> <2e483546-f34f-3c96-a2aa-6d7b4fc47cc2@redhat.com> Message-ID: Hi Liu Xin, Based on what Andrew said about UseCondCardMark, I agree with Martin that we go with your new backport webrev for 8135018 first. My only concern is that we changed to store CardTableModRefBS::dirty_card_val() instead of constant zero to card_addr in c1_LIRGenerator.cpp. It looks to me unnecessary to add this change when you are adding the missing memory bars. So I suggest we do: diff -r 09d4b646f756 src/share/vm/c1/c1_LIRGenerator.cpp --- a/src/share/vm/c1/c1_LIRGenerator.cpp Tue Nov 12 17:54:52 2019 +0800 +++ b/src/share/vm/c1/c1_LIRGenerator.cpp Mon Dec 16 19:17:51 2019 +0800 @@ -1622,10 +1622,16 @@ if (can_inline_as_constant(card_table_base)) { __ move(LIR_OprFact::intConst(0), new LIR_Address(tmp, card_table_base->as_jint(), T_BYTE)); + if (UseConcMarkSweepGC && CMSPrecleaningEnabled) { + __ membar_storestore(); + } } else { __ move(LIR_OprFact::intConst(0), new LIR_Address(tmp, load_constant(card_table_base), T_BYTE)); + if (UseConcMarkSweepGC && CMSPrecleaningEnabled) { + __ membar_storestore(); + } } #endif } Thanks, Felix > > From: Liu Xin > Sent: Montag, 16. Dezember 2019 10:48 > To: Andrew Haley > Cc: Doerr, Martin ; > aarch64-port-dev at openjdk.java.net; Hohensee, Paul > > Subject: Re: RFR 8135018: AARCH64: Missing memory barriers for CMS > collector > > Hi, Andrew and Felix, > > I did backport as Felix suggested. To get UseCondCardMark, we need to > backport other 3 patches. > > hg qseries as follows ( applied in order) > 8076987: https://cr.openjdk.java.net/~xliu/8076987/00/webrev/ > 8078438: https://cr.openjdk.java.net/~xliu/8078438/00/webrev/ > 8079315: https://cr.openjdk.java.net/~xliu/8079315/00/webrev/ > 8135018: https://cr.openjdk.java.net/~xliu/8135018/02/webrev/ > > As Andrew pointed out, I also notice that it introduces a storeLoad membar for > interpreter if UseCondCardMark is on. > The reason I didn't backport UseCondCardMark at first place because it's off by > default. I need to run all tests again with the new parameter > -XX:+UseCondCardMark to validate it. Another reason is that all performance > evaluation was done on x86_64. > It's really time consuming to evaluate performance impact on aarch64. So I > shortcut to fix my primary bug. > > Could you sponsor my previous webrev? > https://cr.openjdk.java.net/~xliu/8135018/01/webrev/ > > It does have a conflict with c1_LIRGenerator.cpp. How about I send another > webrev to jdk8u and update it as well? > > thanks, > --lx > > > On Mon, Dec 16, 2019 at 1:00 AM Andrew Haley > > wrote: > On 12/14/19 4:47 AM, Liu Xin wrote: > > I trace the feature UseCondCardMark. It was introduced by the > > following changes. > > https://bugs.openjdk.java.net/browse/JDK-8076987 C1 > > https://bugs.openjdk.java.net/browse/JDK-8078438 interpreter > > UseCondCardMark is only supported by C2 currently. > > UseCondCardMark was supposed to be a performance enhancement for very > large multi-core systems, but we realized that it needed a StoreLoad barrier. > Because StoreLoad is so expensive there is no performance advantage, > therefore as far as I can see the whole UseCondCardMark exercise is a waste > of time. There is no point back-porting changes to the interpreter and C1. > > Unless someone does some performance measurements to prove that there is > some performance gain in C1 and the interpreter, UseCondCardMark changes > should not be back-ported. > > -- > Andrew Haley (he/him) > Java Platform Lead Engineer > Red Hat UK Ltd. https://keybase.io/andrewhaley > EAC8 43EB D3EF DB98 CC77 2FAD A5CD 6035 332F A671 From felix.yang at huawei.com Mon Dec 16 11:26:06 2019 From: felix.yang at huawei.com (Yangfei (Felix)) Date: Mon, 16 Dec 2019 11:26:06 +0000 Subject: [aarch64-port-dev ] RFR 8135018: AARCH64: Missing memory barriers for CMS collector References: <2b433414-fab1-c63d-1e07-76ddd4abe298@redhat.com> <42729c1e-f90a-2a8d-cd48-c50e7a160245@redhat.com> <2e483546-f34f-3c96-a2aa-6d7b4fc47cc2@redhat.com> Message-ID: Sorry, I think I made a mistake for the patch in my previous mail. Should be: diff -r 09d4b646f756 src/share/vm/c1/c1_LIRGenerator.cpp --- a/src/share/vm/c1/c1_LIRGenerator.cpp Tue Nov 12 17:54:52 2019 +0800 +++ b/src/share/vm/c1/c1_LIRGenerator.cpp Mon Dec 16 19:24:38 2019 +0800 @@ -1619,6 +1619,9 @@ } else { __ unsigned_shift_right(addr, CardTableModRefBS::card_shift, tmp); } + if (UseConcMarkSweepGC && CMSPrecleaningEnabled) { + __ membar_storestore(); + } if (can_inline_as_constant(card_table_base)) { __ move(LIR_OprFact::intConst(0), new LIR_Address(tmp, card_table_base->as_jint(), T_BYTE)); > > Hi Liu Xin, > > Based on what Andrew said about UseCondCardMark, I agree with Martin > that we go with your new backport webrev for 8135018 first. > My only concern is that we changed to store > CardTableModRefBS::dirty_card_val() instead of constant zero to card_addr in > c1_LIRGenerator.cpp. > It looks to me unnecessary to add this change when you are adding the > missing memory bars. > So I suggest we do: > > diff -r 09d4b646f756 src/share/vm/c1/c1_LIRGenerator.cpp > --- a/src/share/vm/c1/c1_LIRGenerator.cpp Tue Nov 12 17:54:52 2019 > +0800 > +++ b/src/share/vm/c1/c1_LIRGenerator.cpp Mon Dec 16 19:17:51 > 2019 +0800 > @@ -1622,10 +1622,16 @@ > if (can_inline_as_constant(card_table_base)) { > __ move(LIR_OprFact::intConst(0), > new LIR_Address(tmp, card_table_base->as_jint(), > T_BYTE)); > + if (UseConcMarkSweepGC && CMSPrecleaningEnabled) { > + __ membar_storestore(); > + } > } else { > __ move(LIR_OprFact::intConst(0), > new LIR_Address(tmp, load_constant(card_table_base), > T_BYTE)); > + if (UseConcMarkSweepGC && CMSPrecleaningEnabled) { > + __ membar_storestore(); > + } > } > #endif > } > > > Thanks, > Felix > > > > > From: Liu Xin > > Sent: Montag, 16. Dezember 2019 10:48 > > To: Andrew Haley > > Cc: Doerr, Martin ; > > aarch64-port-dev at openjdk.java.net; Hohensee, Paul > > > > Subject: Re: RFR 8135018: AARCH64: Missing memory barriers for CMS > > collector > > > > Hi, Andrew and Felix, > > > > I did backport as Felix suggested. To get UseCondCardMark, we need to > > backport other 3 patches. > > > > hg qseries as follows ( applied in order) > > 8076987: https://cr.openjdk.java.net/~xliu/8076987/00/webrev/ > > 8078438: https://cr.openjdk.java.net/~xliu/8078438/00/webrev/ > > 8079315: https://cr.openjdk.java.net/~xliu/8079315/00/webrev/ > > 8135018: https://cr.openjdk.java.net/~xliu/8135018/02/webrev/ > > > > As Andrew pointed out, I also notice that it introduces a storeLoad > > membar for interpreter if UseCondCardMark is on. > > The reason I didn't backport UseCondCardMark at first place because > > it's off by default. I need to run all tests again with the new > > parameter -XX:+UseCondCardMark to validate it. Another reason is that > > all performance evaluation was done on x86_64. > > It's really time consuming to evaluate performance impact on aarch64. > > So I shortcut to fix my primary bug. > > > > Could you sponsor my previous webrev? > > https://cr.openjdk.java.net/~xliu/8135018/01/webrev/ > > > > It does have a conflict with c1_LIRGenerator.cpp. How about I send > > another webrev to jdk8u and update it as well? > > > > thanks, > > --lx > > > > > > On Mon, Dec 16, 2019 at 1:00 AM Andrew Haley > > > wrote: > > On 12/14/19 4:47 AM, Liu Xin wrote: > > > I trace the feature UseCondCardMark. It was introduced by the > > > following changes. > > > https://bugs.openjdk.java.net/browse/JDK-8076987 C1 > > > https://bugs.openjdk.java.net/browse/JDK-8078438 interpreter > > > UseCondCardMark is only supported by C2 currently. > > > > UseCondCardMark was supposed to be a performance enhancement for very > > large multi-core systems, but we realized that it needed a StoreLoad barrier. > > Because StoreLoad is so expensive there is no performance advantage, > > therefore as far as I can see the whole UseCondCardMark exercise is a > > waste of time. There is no point back-porting changes to the interpreter and > C1. > > > > Unless someone does some performance measurements to prove that there > > is some performance gain in C1 and the interpreter, UseCondCardMark > > changes should not be back-ported. > > > > -- > > Andrew Haley (he/him) > > Java Platform Lead Engineer > > Red Hat UK Ltd. > > https://keybase.io/andrewhaley > > EAC8 43EB D3EF DB98 CC77 2FAD A5CD 6035 332F A671 From felix.yang at huawei.com Mon Dec 16 11:36:49 2019 From: felix.yang at huawei.com (Yangfei (Felix)) Date: Mon, 16 Dec 2019 11:36:49 +0000 Subject: [aarch64-port-dev ] RFR 8135018: AARCH64: Missing memory barriers for CMS collector In-Reply-To: References: <2b433414-fab1-c63d-1e07-76ddd4abe298@redhat.com> <42729c1e-f90a-2a8d-cd48-c50e7a160245@redhat.com> <2e483546-f34f-3c96-a2aa-6d7b4fc47cc2@redhat.com> Message-ID: Yes, I noticed that ? https://mail.openjdk.java.net/pipermail/aarch64-port-dev/2019-December/008389.html From: Liu Xin [mailto:navy.xliu at gmail.com] Sent: Monday, December 16, 2019 7:35 PM To: Yangfei (Felix) Cc: aarch64-port-dev at openjdk.java.net; Andrew Haley ; Doerr, Martin Subject: Re: [aarch64-port-dev ] RFR 8135018: AARCH64: Missing memory barriers for CMS collector hi, Felix, The original storestore appears right before strb. your membar(storeStore) is after strb. is it the same? if it's same, we can place membar out of if/else to dedup. diff --git a/src/hotspot/src/share/vm/c1/c1_LIRGenerator.cpp b/src/hotspot/src/share/vm/c1/c1_LIRGenerator.cpp index 19ec64d8..068f0797 100644 --- a/src/hotspot/src/share/vm/c1/c1_LIRGenerator.cpp +++ b/src/hotspot/src/share/vm/c1/c1_LIRGenerator.cpp @@ -1615,6 +1615,9 @@ void LIRGenerator::CardTableModRef_post_barrier(LIR_OprDesc* addr, LIR_OprDesc* new LIR_Address(tmp, load_constant(card_table_base), T_BYTE)); } + if (UseConcMarkSweepGC && CMSPrecleaningEnabled) { + __ membar_storestore(); + } #endif } On Mon, Dec 16, 2019 at 3:21 AM Yangfei (Felix) > wrote: Hi Liu Xin, Based on what Andrew said about UseCondCardMark, I agree with Martin that we go with your new backport webrev for 8135018 first. My only concern is that we changed to store CardTableModRefBS::dirty_card_val() instead of constant zero to card_addr in c1_LIRGenerator.cpp. It looks to me unnecessary to add this change when you are adding the missing memory bars. So I suggest we do: diff -r 09d4b646f756 src/share/vm/c1/c1_LIRGenerator.cpp --- a/src/share/vm/c1/c1_LIRGenerator.cpp Tue Nov 12 17:54:52 2019 +0800 +++ b/src/share/vm/c1/c1_LIRGenerator.cpp Mon Dec 16 19:17:51 2019 +0800 @@ -1622,10 +1622,16 @@ if (can_inline_as_constant(card_table_base)) { __ move(LIR_OprFact::intConst(0), new LIR_Address(tmp, card_table_base->as_jint(), T_BYTE)); + if (UseConcMarkSweepGC && CMSPrecleaningEnabled) { + __ membar_storestore(); + } } else { __ move(LIR_OprFact::intConst(0), new LIR_Address(tmp, load_constant(card_table_base), T_BYTE)); + if (UseConcMarkSweepGC && CMSPrecleaningEnabled) { + __ membar_storestore(); + } } #endif } Thanks, Felix > > From: Liu Xin > > Sent: Montag, 16. Dezember 2019 10:48 > To: Andrew Haley > > Cc: Doerr, Martin >; > aarch64-port-dev at openjdk.java.net; Hohensee, Paul > > > Subject: Re: RFR 8135018: AARCH64: Missing memory barriers for CMS > collector > > Hi, Andrew and Felix, > > I did backport as Felix suggested. To get UseCondCardMark, we need to > backport other 3 patches. > > hg qseries as follows ( applied in order) > 8076987: https://cr.openjdk.java.net/~xliu/8076987/00/webrev/ > 8078438: https://cr.openjdk.java.net/~xliu/8078438/00/webrev/ > 8079315: https://cr.openjdk.java.net/~xliu/8079315/00/webrev/ > 8135018: https://cr.openjdk.java.net/~xliu/8135018/02/webrev/ > > As Andrew pointed out, I also notice that it introduces a storeLoad membar for > interpreter if UseCondCardMark is on. > The reason I didn't backport UseCondCardMark at first place because it's off by > default. I need to run all tests again with the new parameter > -XX:+UseCondCardMark to validate it. Another reason is that all performance > evaluation was done on x86_64. > It's really time consuming to evaluate performance impact on aarch64. So I > shortcut to fix my primary bug. > > Could you sponsor my previous webrev? > https://cr.openjdk.java.net/~xliu/8135018/01/webrev/ > > It does have a conflict with c1_LIRGenerator.cpp. How about I send another > webrev to jdk8u and update it as well? > > thanks, > --lx > > > On Mon, Dec 16, 2019 at 1:00 AM Andrew Haley > >> wrote: > On 12/14/19 4:47 AM, Liu Xin wrote: > > I trace the feature UseCondCardMark. It was introduced by the > > following changes. > > https://bugs.openjdk.java.net/browse/JDK-8076987 C1 > > https://bugs.openjdk.java.net/browse/JDK-8078438 interpreter > > UseCondCardMark is only supported by C2 currently. > > UseCondCardMark was supposed to be a performance enhancement for very > large multi-core systems, but we realized that it needed a StoreLoad barrier. > Because StoreLoad is so expensive there is no performance advantage, > therefore as far as I can see the whole UseCondCardMark exercise is a waste > of time. There is no point back-porting changes to the interpreter and C1. > > Unless someone does some performance measurements to prove that there is > some performance gain in C1 and the interpreter, UseCondCardMark changes > should not be back-ported. > > -- > Andrew Haley (he/him) > Java Platform Lead Engineer > Red Hat UK Ltd. https://keybase.io/andrewhaley > EAC8 43EB D3EF DB98 CC77 2FAD A5CD 6035 332F A671 From gnu.andrew at redhat.com Mon Dec 16 16:41:06 2019 From: gnu.andrew at redhat.com (Andrew John Hughes) Date: Mon, 16 Dec 2019 16:41:06 +0000 Subject: [aarch64-port-dev ] RFR: Merge late fix from shenandoah/jdk8 In-Reply-To: <22715056-0ca4-5be6-be98-988e8c7950f1@redhat.com> References: <22715056-0ca4-5be6-be98-988e8c7950f1@redhat.com> Message-ID: <00acf32c-4b37-ee66-28b4-302b188f5a38@redhat.com> On 16/12/2019 10:46, Roman Kennke wrote: > Hi there, > > right after I brought in the big Shenandoah merge, a user reported a > bug, which is shenandoah/jdk8 specific and which I fixed on Friday. I'd > like to include it in the integration repo. It is this fix: > > http://hg.openjdk.java.net/shenandoah/jdk8/hotspot/rev/353510f8073a > > It applies and merges cleanly. > > Testing: it went through our CI several times over the weekend. > > Roman > Ok with me. It'd be good if you could push this ASAP, so I can include it in the merge in my next webrev. Thanks, -- Andrew :) Senior Free Java Software Engineer Red Hat, Inc. (http://www.redhat.com) PGP Key: ed25519/0xCFDA0F9B35964222 (hkp://keys.gnupg.net) Fingerprint = 5132 579D D154 0ED2 3E04 C5A0 CFDA 0F9B 3596 4222 https://keybase.io/gnu_andrew From rkennke at redhat.com Mon Dec 16 16:55:19 2019 From: rkennke at redhat.com (rkennke at redhat.com) Date: Mon, 16 Dec 2019 16:55:19 +0000 Subject: [aarch64-port-dev ] hg: aarch64-port/jdk8u-shenandoah/hotspot: 2 new changesets Message-ID: <201912161655.xBGGtJgi017978@aojmv0008.oracle.com> Changeset: 353510f8073a Author: rkennke Date: 2019-12-13 13:49 +0100 URL: https://hg.openjdk.java.net/aarch64-port/jdk8u-shenandoah/hotspot/rev/353510f8073a Cleanup weak JNI refs when not doing reference processing Reviewed-by: zgu ! src/share/vm/gc_implementation/shenandoah/shenandoahConcurrentMark.cpp ! src/share/vm/gc_implementation/shenandoah/shenandoahConcurrentMark.hpp ! src/share/vm/gc_implementation/shenandoah/shenandoahTraversalGC.cpp Changeset: 726fc0e86dc5 Author: rkennke Date: 2019-12-16 11:44 +0100 URL: https://hg.openjdk.java.net/aarch64-port/jdk8u-shenandoah/hotspot/rev/726fc0e86dc5 Merge From navy.xliu at gmail.com Mon Dec 16 09:47:30 2019 From: navy.xliu at gmail.com (Liu Xin) Date: Mon, 16 Dec 2019 01:47:30 -0800 Subject: [aarch64-port-dev ] RFR 8135018: AARCH64: Missing memory barriers for CMS collector In-Reply-To: <2e483546-f34f-3c96-a2aa-6d7b4fc47cc2@redhat.com> References: <2b433414-fab1-c63d-1e07-76ddd4abe298@redhat.com> <42729c1e-f90a-2a8d-cd48-c50e7a160245@redhat.com> <2e483546-f34f-3c96-a2aa-6d7b4fc47cc2@redhat.com> Message-ID: Hi, Andrew and Felix, I did backport as Felix suggested. To get UseCondCardMark, we need to backport other 3 patches. hg qseries as follows ( applied in order) 8076987: https://cr.openjdk.java.net/~xliu/8076987/00/webrev/ 8078438: https://cr.openjdk.java.net/~xliu/8078438/00/webrev/ 8079315: https://cr.openjdk.java.net/~xliu/8079315/00/webrev/ 8135018: https://cr.openjdk.java.net/~xliu/8135018/02/webrev/ As Andrew pointed out, I also notice that it introduces a storeLoad membar for interpreter if UseCondCardMark is on. The reason I didn't backport UseCondCardMark at first place because it's off by default. I need to run all tests again with the new parameter -XX:+UseCondCardMark to validate it. Another reason is that all performance evaluation was done on x86_64. It's really time consuming to evaluate performance impact on aarch64. So I shortcut to fix my primary bug. Could you sponsor my previous webrev? https://cr.openjdk.java.net/~xliu/8135018/01/webrev/ It does have a conflict with c1_LIRGenerator.cpp. How about I send another webrev to jdk8u and update it as well? thanks, --lx On Mon, Dec 16, 2019 at 1:00 AM Andrew Haley wrote: > On 12/14/19 4:47 AM, Liu Xin wrote: > > I trace the feature UseCondCardMark. It was > > introduced by the following changes. > > https://bugs.openjdk.java.net/browse/JDK-8076987 C1 > > https://bugs.openjdk.java.net/browse/JDK-8078438 interpreter > > UseCondCardMark is only supported by C2 currently. > > UseCondCardMark was supposed to be a performance enhancement for > very large multi-core systems, but we realized that it needed a > StoreLoad barrier. Because StoreLoad is so expensive there is no > performance advantage, therefore as far as I can see the whole > UseCondCardMark exercise is a waste of time. There is no point > back-porting changes to the interpreter and C1. > > Unless someone does some performance measurements to prove that > there is some performance gain in C1 and the interpreter, > UseCondCardMark changes should not be back-ported. > > -- > Andrew Haley (he/him) > Java Platform Lead Engineer > Red Hat UK Ltd. > https://keybase.io/andrewhaley > EAC8 43EB D3EF DB98 CC77 2FAD A5CD 6035 332F A671 > > From navy.xliu at gmail.com Mon Dec 16 11:20:26 2019 From: navy.xliu at gmail.com (Liu Xin) Date: Mon, 16 Dec 2019 03:20:26 -0800 Subject: [aarch64-port-dev ] RFR 8135018: AARCH64: Missing memory barriers for CMS collector In-Reply-To: References: <2b433414-fab1-c63d-1e07-76ddd4abe298@redhat.com> <42729c1e-f90a-2a8d-cd48-c50e7a160245@redhat.com> <2e483546-f34f-3c96-a2aa-6d7b4fc47cc2@redhat.com> Message-ID: hi, Martin, Thanks for the good advice. My stand is this webrev. https://cr.openjdk.java.net/~xliu/8135018/01/ My arguments are: 1. JDK-8078438 probably never land to jdk8u because Andrew said it isn't worth doing. I understand your concern. I can leave a comment to JDK-8078438 as reminder, in case it happens. 2. For me, I'd like to solve a bug once a time. It's very easy to have a mushroom-effect if we backport everything verbatim. A bug may creep into those vertigo patches. 3. I agree with Felix's comment that the patch causes a conflict between jdk8u and jdk8u-shenandoah. I propose to have another webrev of c1_LIRGenerator.cpp in jdk8u. thanks, --lx On Mon, Dec 16, 2019 at 2:28 AM Doerr, Martin wrote: > Hi Ix, > > > > I would only recommend pushing your new webrev if it?s clear that > JDK-8078438 will never get backported. > > Otherwise, the membar in MacroAssembler::store_check will be missing if it > doesn?t get added back manually. > > If we go this way, I suggest to add a comment to JDK-8078438 as reminder. > > > > I don?t think performance measurements were needed because the membar is > required for correctness. And, as you said, the feature is off by default > and I wonder who would ever turn it on. > > > > Best regards, > > Martin > > > > > > *From:* Liu Xin > *Sent:* Montag, 16. Dezember 2019 10:48 > *To:* Andrew Haley > *Cc:* Doerr, Martin ; > aarch64-port-dev at openjdk.java.net; Hohensee, Paul > *Subject:* Re: RFR 8135018: AARCH64: Missing memory barriers for CMS > collector > > > > Hi, Andrew and Felix, > > > > I did backport as Felix suggested. To get UseCondCardMark, we need to > backport other 3 patches. > > > > hg qseries as follows ( applied in order) > 8076987: https://cr.openjdk.java.net/~xliu/8076987/00/webrev/ > 8078438: https://cr.openjdk.java.net/~xliu/8078438/00/webrev/ > 8079315: https://cr.openjdk.java.net/~xliu/8079315/00/webrev/ > 8135018: https://cr.openjdk.java.net/~xliu/8135018/02/webrev/ > > > > As Andrew pointed out, I also notice that it introduces a storeLoad membar > for interpreter if UseCondCardMark is on. > > The reason I didn't backport UseCondCardMark at first place because it's > off by default. I need to run all tests again with the new parameter > -XX:+UseCondCardMark to validate it. Another reason is that all > performance evaluation was done on x86_64. > > It's really time consuming to evaluate performance impact on aarch64. So > I shortcut to fix my primary bug. > > > > Could you sponsor my previous webrev? > > https://cr.openjdk.java.net/~xliu/8135018/01/webrev/ > > > > It does have a conflict with c1_LIRGenerator.cpp. How about I send another > webrev to jdk8u and update it as well? > > > > thanks, > > --lx > > > > > > On Mon, Dec 16, 2019 at 1:00 AM Andrew Haley wrote: > > On 12/14/19 4:47 AM, Liu Xin wrote: > > I trace the feature UseCondCardMark. It was > > introduced by the following changes. > > https://bugs.openjdk.java.net/browse/JDK-8076987 C1 > > https://bugs.openjdk.java.net/browse/JDK-8078438 interpreter > > UseCondCardMark is only supported by C2 currently. > > UseCondCardMark was supposed to be a performance enhancement for > very large multi-core systems, but we realized that it needed a > StoreLoad barrier. Because StoreLoad is so expensive there is no > performance advantage, therefore as far as I can see the whole > UseCondCardMark exercise is a waste of time. There is no point > back-porting changes to the interpreter and C1. > > Unless someone does some performance measurements to prove that > there is some performance gain in C1 and the interpreter, > UseCondCardMark changes should not be back-ported. > > -- > Andrew Haley (he/him) > Java Platform Lead Engineer > Red Hat UK Ltd. > https://keybase.io/andrewhaley > EAC8 43EB D3EF DB98 CC77 2FAD A5CD 6035 332F A671 > > From navy.xliu at gmail.com Sat Dec 14 04:47:13 2019 From: navy.xliu at gmail.com (Liu Xin) Date: Fri, 13 Dec 2019 20:47:13 -0800 Subject: [aarch64-port-dev ] RFR 8135018: AARCH64: Missing memory barriers for CMS collector In-Reply-To: References: <2b433414-fab1-c63d-1e07-76ddd4abe298@redhat.com> <42729c1e-f90a-2a8d-cd48-c50e7a160245@redhat.com> Message-ID: hi, Andrew and Martin, Thanks you to review my patch. I trace the feature UseCondCardMark. It was introduced by the following changes. https://bugs.openjdk.java.net/browse/JDK-8076987 C1 https://bugs.openjdk.java.net/browse/JDK-8078438 interpreter UseCondCardMark is only supported by C2 currently. Yes, my original patch does miss hunk -- the x86 part. That's why I propose a new webrev here. It's almost a clean backport for JDK-8135018. Let's solve the missing barrier bug first. Could you take a look at it? https://cr.openjdk.java.net/~xliu/8135018/01/webrev/ I have verified it using hotspot:tier1 on aarch64. I also eyeballed the generated code. If -XX:+UseConcMarkSweepGC is present, the membar(StoreStore) is inserted as expected. 0x0000ffff7c317f58: lsr x0, x1, #9 0x0000ffff7c317f5c: mov x1, #0xd000 // #53248 0x0000ffff7c317f60: movk x1, #0x4fdf, lsl #16 0x0000ffff7c317f64: movk x1, #0xffff, lsl #32 0x0000ffff7c317f68: dmb ishst 0x0000ffff7c317f6c: strb wzr, [x0, x1, lsl #0] ;*putfield arr ; - ByteTest::actor1 at 4 (line 5) thanks, --lx On Fri, Dec 13, 2019 at 7:21 AM Andrew Haley wrote: > On 12/13/19 1:38 PM, Doerr, Martin wrote: > > I guess the change would apply cleanly on top of > > http://hg.openjdk.java.net/jdk9/jdk9/hotspot/rev/4a179f93d775 > > > > If it's easy to backport (I haven't tried) doing that one first should > be the preferred way. > > > > But if that change is not wanted in 8u, I'll be fine with Ix's version. > > Having the UseCondCardMark code only at some places wouldn't break > anything. There's no consistency requirement. > > OK, but I'm trying to understand what is going on. Either UseCondCardMark > is > supported by AArch64 in JDK 8 or it is not. If it is not, then all we have > to do is insert any missing memory barriers. If it's supposed to be, then > we should be consistent. > > -- > Andrew Haley (he/him) > Java Platform Lead Engineer > Red Hat UK Ltd. > https://keybase.io/andrewhaley > EAC8 43EB D3EF DB98 CC77 2FAD A5CD 6035 332F A671 > > From navy.xliu at gmail.com Mon Dec 16 11:34:38 2019 From: navy.xliu at gmail.com (Liu Xin) Date: Mon, 16 Dec 2019 03:34:38 -0800 Subject: [aarch64-port-dev ] RFR 8135018: AARCH64: Missing memory barriers for CMS collector In-Reply-To: References: <2b433414-fab1-c63d-1e07-76ddd4abe298@redhat.com> <42729c1e-f90a-2a8d-cd48-c50e7a160245@redhat.com> <2e483546-f34f-3c96-a2aa-6d7b4fc47cc2@redhat.com> Message-ID: hi, Felix, The original storestore appears right before strb. your membar(storeStore) is after strb. is it the same? if it's same, we can place membar out of if/else to dedup. diff --git a/src/hotspot/src/share/vm/c1/c1_LIRGenerator.cpp b/src/hotspot/src/share/vm/c1/c1_LIRGenerator.cpp index 19ec64d8..068f0797 100644 --- a/src/hotspot/src/share/vm/c1/c1_LIRGenerator.cpp +++ b/src/hotspot/src/share/vm/c1/c1_LIRGenerator.cpp @@ -1615,6 +1615,9 @@ void LIRGenerator::CardTableModRef_post_barrier(LIR_OprDesc* addr, LIR_OprDesc* new LIR_Address(tmp, load_constant(card_table_base), T_BYTE)); } + if (UseConcMarkSweepGC && CMSPrecleaningEnabled) { + __ membar_storestore(); + } #endif } On Mon, Dec 16, 2019 at 3:21 AM Yangfei (Felix) wrote: > Hi Liu Xin, > > Based on what Andrew said about UseCondCardMark, I agree with Martin > that we go with your new backport webrev for 8135018 first. > My only concern is that we changed to store > CardTableModRefBS::dirty_card_val() instead of constant zero to card_addr > in c1_LIRGenerator.cpp. > It looks to me unnecessary to add this change when you are adding the > missing memory bars. > So I suggest we do: > > diff -r 09d4b646f756 src/share/vm/c1/c1_LIRGenerator.cpp > --- a/src/share/vm/c1/c1_LIRGenerator.cpp Tue Nov 12 17:54:52 2019 > +0800 > +++ b/src/share/vm/c1/c1_LIRGenerator.cpp Mon Dec 16 19:17:51 2019 > +0800 > @@ -1622,10 +1622,16 @@ > if (can_inline_as_constant(card_table_base)) { > __ move(LIR_OprFact::intConst(0), > new LIR_Address(tmp, card_table_base->as_jint(), T_BYTE)); > + if (UseConcMarkSweepGC && CMSPrecleaningEnabled) { > + __ membar_storestore(); > + } > } else { > __ move(LIR_OprFact::intConst(0), > new LIR_Address(tmp, load_constant(card_table_base), > T_BYTE)); > + if (UseConcMarkSweepGC && CMSPrecleaningEnabled) { > + __ membar_storestore(); > + } > } > #endif > } > > > Thanks, > Felix > > > > > From: Liu Xin > > Sent: Montag, 16. Dezember 2019 10:48 > > To: Andrew Haley > > Cc: Doerr, Martin ; > > aarch64-port-dev at openjdk.java.net; Hohensee, Paul > > > > Subject: Re: RFR 8135018: AARCH64: Missing memory barriers for CMS > > collector > > > > Hi, Andrew and Felix, > > > > I did backport as Felix suggested. To get UseCondCardMark, we need to > > backport other 3 patches. > > > > hg qseries as follows ( applied in order) > > 8076987: https://cr.openjdk.java.net/~xliu/8076987/00/webrev/ > > 8078438: https://cr.openjdk.java.net/~xliu/8078438/00/webrev/ > > 8079315: https://cr.openjdk.java.net/~xliu/8079315/00/webrev/ > > 8135018: https://cr.openjdk.java.net/~xliu/8135018/02/webrev/ > > > > As Andrew pointed out, I also notice that it introduces a storeLoad > membar for > > interpreter if UseCondCardMark is on. > > The reason I didn't backport UseCondCardMark at first place because it's > off by > > default. I need to run all tests again with the new parameter > > -XX:+UseCondCardMark to validate it. Another reason is that all > performance > > evaluation was done on x86_64. > > It's really time consuming to evaluate performance impact on aarch64. > So I > > shortcut to fix my primary bug. > > > > Could you sponsor my previous webrev? > > https://cr.openjdk.java.net/~xliu/8135018/01/webrev/ > > > > It does have a conflict with c1_LIRGenerator.cpp. How about I send > another > > webrev to jdk8u and update it as well? > > > > thanks, > > --lx > > > > > > On Mon, Dec 16, 2019 at 1:00 AM Andrew Haley > > > wrote: > > On 12/14/19 4:47 AM, Liu Xin wrote: > > > I trace the feature UseCondCardMark. It was introduced by the > > > following changes. > > > https://bugs.openjdk.java.net/browse/JDK-8076987 C1 > > > https://bugs.openjdk.java.net/browse/JDK-8078438 interpreter > > > UseCondCardMark is only supported by C2 currently. > > > > UseCondCardMark was supposed to be a performance enhancement for very > > large multi-core systems, but we realized that it needed a StoreLoad > barrier. > > Because StoreLoad is so expensive there is no performance advantage, > > therefore as far as I can see the whole UseCondCardMark exercise is a > waste > > of time. There is no point back-porting changes to the interpreter and > C1. > > > > Unless someone does some performance measurements to prove that there is > > some performance gain in C1 and the interpreter, UseCondCardMark changes > > should not be back-ported. > > > > -- > > Andrew Haley (he/him) > > Java Platform Lead Engineer > > Red Hat UK Ltd. https://keybase.io/andrewhaley > > EAC8 43EB D3EF DB98 CC77 2FAD A5CD 6035 332F A671 > From navy.xliu at gmail.com Mon Dec 16 11:54:38 2019 From: navy.xliu at gmail.com (Liu Xin) Date: Mon, 16 Dec 2019 03:54:38 -0800 Subject: [aarch64-port-dev ] RFR 8135018: AARCH64: Missing memory barriers for CMS collector In-Reply-To: References: <2b433414-fab1-c63d-1e07-76ddd4abe298@redhat.com> <42729c1e-f90a-2a8d-cd48-c50e7a160245@redhat.com> <2e483546-f34f-3c96-a2aa-6d7b4fc47cc2@redhat.com> Message-ID: "store store barriers" http://gee.cs.oswego.edu/dl/jmm/cookbook.html I think the JDK-8135018 inserts a membar(StoreStore) in the middle of put_field and update_cardTable on purpose. it can guarantee memory orders seen by Concurrent Mark Threads. if you put the storestore membar after two stores, IMHO, the hazard is still there. On Mon, Dec 16, 2019 at 3:34 AM Liu Xin wrote: > hi, Felix, > > The original storestore appears right before strb. your > membar(storeStore) is after strb. is it the same? > if it's same, we can place membar out of if/else to dedup. > > > diff --git a/src/hotspot/src/share/vm/c1/c1_LIRGenerator.cpp > b/src/hotspot/src/share/vm/c1/c1_LIRGenerator.cpp > index 19ec64d8..068f0797 100644 > --- a/src/hotspot/src/share/vm/c1/c1_LIRGenerator.cpp > +++ b/src/hotspot/src/share/vm/c1/c1_LIRGenerator.cpp > @@ -1615,6 +1615,9 @@ void > LIRGenerator::CardTableModRef_post_barrier(LIR_OprDesc* addr, LIR_OprDesc* > new LIR_Address(tmp, load_constant(card_table_base), > T_BYTE)); > } > + if (UseConcMarkSweepGC && CMSPrecleaningEnabled) { > + __ membar_storestore(); > + } > #endif > } > > On Mon, Dec 16, 2019 at 3:21 AM Yangfei (Felix) > wrote: > >> Hi Liu Xin, >> >> Based on what Andrew said about UseCondCardMark, I agree with Martin >> that we go with your new backport webrev for 8135018 first. >> My only concern is that we changed to store >> CardTableModRefBS::dirty_card_val() instead of constant zero to card_addr >> in c1_LIRGenerator.cpp. >> It looks to me unnecessary to add this change when you are adding the >> missing memory bars. >> So I suggest we do: >> >> diff -r 09d4b646f756 src/share/vm/c1/c1_LIRGenerator.cpp >> --- a/src/share/vm/c1/c1_LIRGenerator.cpp Tue Nov 12 17:54:52 2019 >> +0800 >> +++ b/src/share/vm/c1/c1_LIRGenerator.cpp Mon Dec 16 19:17:51 2019 >> +0800 >> @@ -1622,10 +1622,16 @@ >> if (can_inline_as_constant(card_table_base)) { >> __ move(LIR_OprFact::intConst(0), >> new LIR_Address(tmp, card_table_base->as_jint(), T_BYTE)); >> + if (UseConcMarkSweepGC && CMSPrecleaningEnabled) { >> + __ membar_storestore(); >> + } >> } else { >> __ move(LIR_OprFact::intConst(0), >> new LIR_Address(tmp, load_constant(card_table_base), >> T_BYTE)); >> + if (UseConcMarkSweepGC && CMSPrecleaningEnabled) { >> + __ membar_storestore(); >> + } >> } >> #endif >> } >> >> >> Thanks, >> Felix >> >> > >> > From: Liu Xin >> > Sent: Montag, 16. Dezember 2019 10:48 >> > To: Andrew Haley >> > Cc: Doerr, Martin ; >> > aarch64-port-dev at openjdk.java.net; Hohensee, Paul >> > >> > Subject: Re: RFR 8135018: AARCH64: Missing memory barriers for CMS >> > collector >> > >> > Hi, Andrew and Felix, >> > >> > I did backport as Felix suggested. To get UseCondCardMark, we need to >> > backport other 3 patches. >> > >> > hg qseries as follows ( applied in order) >> > 8076987: https://cr.openjdk.java.net/~xliu/8076987/00/webrev/ >> > 8078438: https://cr.openjdk.java.net/~xliu/8078438/00/webrev/ >> > 8079315: https://cr.openjdk.java.net/~xliu/8079315/00/webrev/ >> > 8135018: https://cr.openjdk.java.net/~xliu/8135018/02/webrev/ >> > >> > As Andrew pointed out, I also notice that it introduces a storeLoad >> membar for >> > interpreter if UseCondCardMark is on. >> > The reason I didn't backport UseCondCardMark at first place because >> it's off by >> > default. I need to run all tests again with the new parameter >> > -XX:+UseCondCardMark to validate it. Another reason is that all >> performance >> > evaluation was done on x86_64. >> > It's really time consuming to evaluate performance impact on aarch64. >> So I >> > shortcut to fix my primary bug. >> > >> > Could you sponsor my previous webrev? >> > https://cr.openjdk.java.net/~xliu/8135018/01/webrev/ >> > >> > It does have a conflict with c1_LIRGenerator.cpp. How about I send >> another >> > webrev to jdk8u and update it as well? >> > >> > thanks, >> > --lx >> > >> > >> > On Mon, Dec 16, 2019 at 1:00 AM Andrew Haley >> > > wrote: >> > On 12/14/19 4:47 AM, Liu Xin wrote: >> > > I trace the feature UseCondCardMark. It was introduced by the >> > > following changes. >> > > https://bugs.openjdk.java.net/browse/JDK-8076987 C1 >> > > https://bugs.openjdk.java.net/browse/JDK-8078438 interpreter >> > > UseCondCardMark is only supported by C2 currently. >> > >> > UseCondCardMark was supposed to be a performance enhancement for very >> > large multi-core systems, but we realized that it needed a StoreLoad >> barrier. >> > Because StoreLoad is so expensive there is no performance advantage, >> > therefore as far as I can see the whole UseCondCardMark exercise is a >> waste >> > of time. There is no point back-porting changes to the interpreter and >> C1. >> > >> > Unless someone does some performance measurements to prove that there is >> > some performance gain in C1 and the interpreter, UseCondCardMark changes >> > should not be back-ported. >> > >> > -- >> > Andrew Haley (he/him) >> > Java Platform Lead Engineer >> > Red Hat UK Ltd. https://keybase.io/andrewhaley >> > EAC8 43EB D3EF DB98 CC77 2FAD A5CD 6035 332F A671 >> > From felix.yang at huawei.com Tue Dec 17 01:17:18 2019 From: felix.yang at huawei.com (Yangfei (Felix)) Date: Tue, 17 Dec 2019 01:17:18 +0000 Subject: [aarch64-port-dev ] RFR 8135018: AARCH64: Missing memory barriers for CMS collector In-Reply-To: References: <2b433414-fab1-c63d-1e07-76ddd4abe298@redhat.com> <42729c1e-f90a-2a8d-cd48-c50e7a160245@redhat.com> <2e483546-f34f-3c96-a2aa-6d7b4fc47cc2@redhat.com> Message-ID: Hi Liu Xin, Thanks for preparing a new webrev. That looks good to me (Not a Reviewer). I also run a jcsress with CMS on my aarch64 machine last night. As this backport only add necessary memory barriers, risk should be low. I will push this for you. Felix From: Liu Xin [mailto:navy.xliu at gmail.com] Sent: Tuesday, December 17, 2019 6:23 AM To: Yangfei (Felix) Cc: aarch64-port-dev at openjdk.java.net; Andrew Haley ; Doerr, Martin Subject: Re: [aarch64-port-dev ] RFR 8135018: AARCH64: Missing memory barriers for CMS collector Hi, Reviewers, How about this Webrev? I modified as Felix's suggestion. https://cr.openjdk.java.net/~xliu/8135018/03/webrev/ Passed hotspot:tier1 and jcstress with CMS. From nick.gasson at arm.com Tue Dec 17 06:25:00 2019 From: nick.gasson at arm.com (Nick Gasson) Date: Tue, 17 Dec 2019 14:25:00 +0800 Subject: [aarch64-port-dev ] RFR: 8234794: AArch64: runtime/memory/ReadFromNoaccessArea.java crashes In-Reply-To: References: <917ec3f4-f3a7-8f18-3f80-b1a1c0657318@redhat.com> Message-ID: Hi, Any comments on the most recent webrev below? Thanks, Nick On 12/12/2019 16:31, Nick Gasson wrote: > On 12/12/2019 04:16, Andrew Haley wrote: >> On 12/11/19 7:08 AM, Nick Gasson wrote: >>> Bug: https://bugs.openjdk.java.net/browse/JDK-8234794 >>> Webrev: http://cr.openjdk.java.net/~ngasson/8234794/webrev.01/ >> >> Thanks. A few nits: > > Please see the updated webrev: > > http://cr.openjdk.java.net/~ngasson/8234794/webrev.02/ > >> >> This recalculates klass_decode_mode() a thousand times on only a small >> program. Be aware that C2 creates a new Assembler instance for most >> patterns. >> >> _klass_decode_mode could be calculated only once. Make it static and it >> will be. > > Yes. Also added an assert that Metaspace::initialized() in case we call > it too early. > >> >> This inverted logic: >> >> #if !(defined(AARCH64) || defined(AIX)) >> ?? return ReservedSpace(size, alignment, large_pages, requested_addr); >> #else // AARCH64 || AIX >> >> looks a bit cumbersome. It might be nice to do it the other way up, so >> that reserve_preferred_space is called from a static generic allocate >> method. >> >> Rather than explicitly defined(AARCH64) || defined(AIX) you might like to >> consider a named macro >> >> #if OS_CPU_USES_PREFERRED_SPACE >> ?? return reserve_preferred_space( ... >> endif >> > > OK. Metaspace::reserve_preferred_space() is now only defined if > PREFERRED_METASPACE_ALIGNMENT is set. The generic method is > Metaspace::reserve_space(). MetaspaceShared::reserve_shared_space() is > now just a trivial wrapper for this so maybe it can be removed. > > I put the definition in the CPU's globalDefinitions.hpp because we don't > have one for os_cpu, and we need it for every AArch64 system anyway. > > Also fixed the break/return inconsistency suggested by Jiangli. > > > Thanks, > Nick From ci_notify at linaro.org Tue Dec 17 10:50:31 2019 From: ci_notify at linaro.org (ci_notify at linaro.org) Date: Tue, 17 Dec 2019 10:50:31 +0000 (UTC) Subject: [aarch64-port-dev ] JTREG, JCStress, SPECjbb2015 and Hadoop/Terasort results for OpenJDK JDK on AArch64 Message-ID: <1199176561.5266.1576579832018.JavaMail.javamailuser@localhost> This is a summary of the JTREG test results =========================================== The build and test results are cycled every 15 days. For detailed information on the test output please refer to: http://openjdk.linaro.org/jdkX/openjdk-jtreg-nightly-tests/summary/2019/350/summary.html ------------------------------------------------------------------------------- client-release/hotspot ------------------------------------------------------------------------------- Build 0: aarch64/2018/oct/15 pass: 5,780; fail: 19; not run: 90 ------------------------------------------------------------------------------- client-release/jdk ------------------------------------------------------------------------------- Build 0: aarch64/2018/oct/15 pass: 8,495; fail: 670; error: 23 ------------------------------------------------------------------------------- client-release/langtools ------------------------------------------------------------------------------- Build 0: aarch64/2018/oct/15 pass: 3,970; fail: 5 ------------------------------------------------------------------------------- release/hotspot ------------------------------------------------------------------------------- Build 0: aarch64/2019/nov/13 pass: 5,764; fail: 1 Build 1: aarch64/2019/nov/15 pass: 5,750 Build 2: aarch64/2019/nov/18 pass: 5,750; fail: 1 Build 3: aarch64/2019/nov/20 pass: 5,752 Build 4: aarch64/2019/nov/22 pass: 5,752; fail: 1 Build 5: aarch64/2019/nov/25 pass: 5,752; fail: 1 Build 6: aarch64/2019/nov/27 pass: 5,752; fail: 2 Build 7: aarch64/2019/nov/29 pass: 5,752; fail: 2 Build 8: aarch64/2019/dec/02 pass: 5,753; fail: 4 Build 9: aarch64/2019/dec/04 pass: 5,755; fail: 2 Build 10: aarch64/2019/dec/07 pass: 5,762; fail: 1 Build 11: aarch64/2019/dec/09 pass: 5,762; fail: 1 Build 12: aarch64/2019/dec/11 pass: 5,765; fail: 44 Build 13: aarch64/2019/dec/13 pass: 5,765; fail: 45 Build 14: aarch64/2019/dec/16 pass: 5,764; fail: 45 1 fatal errors were detected; please follow the link above for more detail. ------------------------------------------------------------------------------- release/jdk ------------------------------------------------------------------------------- Build 0: aarch64/2019/nov/13 pass: 8,773; fail: 509; error: 21 Build 1: aarch64/2019/nov/15 pass: 8,756; fail: 511; error: 19 Build 2: aarch64/2019/nov/18 pass: 8,765; fail: 504; error: 18 Build 3: aarch64/2019/nov/20 pass: 8,768; fail: 504; error: 19 Build 4: aarch64/2019/nov/22 pass: 8,769; fail: 507; error: 18 Build 5: aarch64/2019/nov/25 pass: 8,775; fail: 509; error: 17 Build 6: aarch64/2019/nov/27 pass: 8,779; fail: 506; error: 22 Build 7: aarch64/2019/nov/29 pass: 8,784; fail: 503; error: 20 Build 8: aarch64/2019/dec/02 pass: 8,784; fail: 507; error: 19 Build 9: aarch64/2019/dec/04 pass: 8,788; fail: 505; error: 17 Build 10: aarch64/2019/dec/07 pass: 8,819; fail: 524; error: 17 Build 11: aarch64/2019/dec/09 pass: 8,820; fail: 519; error: 21 Build 12: aarch64/2019/dec/11 pass: 8,818; fail: 520; error: 18 Build 13: aarch64/2019/dec/13 pass: 8,811; fail: 530; error: 17 Build 14: aarch64/2019/dec/16 pass: 8,813; fail: 529; error: 17 4 fatal errors were detected; please follow the link above for more detail. ------------------------------------------------------------------------------- release/langtools ------------------------------------------------------------------------------- Build 0: aarch64/2019/nov/13 pass: 3,980 Build 1: aarch64/2019/nov/15 pass: 3,981 Build 2: aarch64/2019/nov/18 pass: 3,981 Build 3: aarch64/2019/nov/20 pass: 3,981 Build 4: aarch64/2019/nov/22 pass: 3,981 Build 5: aarch64/2019/nov/25 pass: 3,983 Build 6: aarch64/2019/nov/27 pass: 4,006 Build 7: aarch64/2019/nov/29 pass: 4,006 Build 8: aarch64/2019/dec/02 pass: 4,002; fail: 5; error: 1 Build 9: aarch64/2019/dec/04 pass: 4,008 Build 10: aarch64/2019/dec/07 pass: 4,019 Build 11: aarch64/2019/dec/09 pass: 4,019 Build 12: aarch64/2019/dec/11 pass: 4,021 Build 13: aarch64/2019/dec/13 pass: 4,029 Build 14: aarch64/2019/dec/16 pass: 4,030 ------------------------------------------------------------------------------- server-release/hotspot ------------------------------------------------------------------------------- Build 0: aarch64/2018/oct/15 pass: 5,787; fail: 18; not run: 90 ------------------------------------------------------------------------------- server-release/jdk ------------------------------------------------------------------------------- Build 0: aarch64/2018/oct/15 pass: 8,476; fail: 686; error: 27 ------------------------------------------------------------------------------- server-release/langtools ------------------------------------------------------------------------------- Build 0: aarch64/2018/oct/15 pass: 3,970; fail: 5 Previous results can be found here: http://openjdk.linaro.org/jdkX/openjdk-jtreg-nightly-tests/index.html SPECjbb2015 composite regression test completed =============================================== This test measures the relative performance of the server compiler running the SPECjbb2015 composite tests and compares the performance against the baseline performance of the server compiler taken on 2016-11-21. In accordance with [1], the SPECjbb2015 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): 8.04x Relative performance: Server critical-jOPS (nc): 12.01x Details of the test setup and historical results may be found here: http://openjdk.linaro.org/jdkX/SPECjbb2015-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 server compiler on 2014-04-01. Relative performance: Zero: 1.0, Server: 210.67 Server 210.67 / Server 2014-04-01 (71.00): 2.97x Details of the test setup and historical results may be found here: http://openjdk.linaro.org/jdkX/hadoop-terasort-benchmark-results/ This is a summary of the jcstress test results ============================================== The build and test results are cycled every 15 days. 2019-11-14 pass rate: 10490/10490, results: http://openjdk.linaro.org/jdkX/jcstress-nightly-runs/2019/317/results/ 2019-11-16 pass rate: 10490/10490, results: http://openjdk.linaro.org/jdkX/jcstress-nightly-runs/2019/319/results/ 2019-11-19 pass rate: 10490/10490, results: http://openjdk.linaro.org/jdkX/jcstress-nightly-runs/2019/322/results/ 2019-11-21 pass rate: 10490/10490, results: http://openjdk.linaro.org/jdkX/jcstress-nightly-runs/2019/324/results/ 2019-11-23 pass rate: 10490/10490, results: http://openjdk.linaro.org/jdkX/jcstress-nightly-runs/2019/326/results/ 2019-11-26 pass rate: 10490/10490, results: http://openjdk.linaro.org/jdkX/jcstress-nightly-runs/2019/329/results/ 2019-12-03 pass rate: 10490/10490, results: http://openjdk.linaro.org/jdkX/jcstress-nightly-runs/2019/331/results/ 2019-12-04 pass rate: 10490/10490, results: http://openjdk.linaro.org/jdkX/jcstress-nightly-runs/2019/333/results/ 2019-12-05 pass rate: 10490/10490, results: http://openjdk.linaro.org/jdkX/jcstress-nightly-runs/2019/336/results/ 2019-12-07 pass rate: 10490/10490, results: http://openjdk.linaro.org/jdkX/jcstress-nightly-runs/2019/338/results/ 2019-12-08 pass rate: 10490/10490, results: http://openjdk.linaro.org/jdkX/jcstress-nightly-runs/2019/341/results/ 2019-12-10 pass rate: 10490/10490, results: http://openjdk.linaro.org/jdkX/jcstress-nightly-runs/2019/343/results/ 2019-12-12 pass rate: 10490/10490, results: http://openjdk.linaro.org/jdkX/jcstress-nightly-runs/2019/345/results/ 2019-12-14 pass rate: 10490/10490, results: http://openjdk.linaro.org/jdkX/jcstress-nightly-runs/2019/347/results/ 2019-12-17 pass rate: 10490/10490, results: http://openjdk.linaro.org/jdkX/jcstress-nightly-runs/2019/350/results/ For detailed information on the test output please refer to: http://openjdk.linaro.org/jdkX/jcstress-nightly-runs/ From aph at redhat.com Tue Dec 17 10:58:23 2019 From: aph at redhat.com (Andrew Haley) Date: Tue, 17 Dec 2019 11:58:23 +0100 Subject: [aarch64-port-dev ] RFR: 8234794: AArch64: runtime/memory/ReadFromNoaccessArea.java crashes In-Reply-To: References: <917ec3f4-f3a7-8f18-3f80-b1a1c0657318@redhat.com> Message-ID: On 12/12/19 8:31 AM, Nick Gasson wrote: > Please see the updated webrev: > > http://cr.openjdk.java.net/~ngasson/8234794/webrev.02/ OK. Good for head, I think. Thanks. -- Andrew Haley (he/him) Java Platform Lead Engineer Red Hat UK Ltd. https://keybase.io/andrewhaley EAC8 43EB D3EF DB98 CC77 2FAD A5CD 6035 332F A671 From adinn at redhat.com Tue Dec 17 11:24:20 2019 From: adinn at redhat.com (Andrew Dinn) Date: Tue, 17 Dec 2019 11:24:20 +0000 Subject: [aarch64-port-dev ] RFR: 8234794: AArch64: runtime/memory/ReadFromNoaccessArea.java crashes In-Reply-To: References: <917ec3f4-f3a7-8f18-3f80-b1a1c0657318@redhat.com> Message-ID: On 12/12/2019 08:31, Nick Gasson wrote: Sorry for not responding -- been recovering from a bad cold. > Please see the updated webrev: > > http://cr.openjdk.java.net/~ngasson/8234794/webrev.02/ Yes, the static init is much better. Looks good. 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 From adinn at redhat.com Tue Dec 17 11:33:40 2019 From: adinn at redhat.com (Andrew Dinn) Date: Tue, 17 Dec 2019 11:33:40 +0000 Subject: [aarch64-port-dev ] RFR: 8235385: AArch64: Crash on aarch64 JDK due to long offset In-Reply-To: <154c82af-865f-d250-395d-6cb9b41b2780@redhat.com> References: <154c82af-865f-d250-395d-6cb9b41b2780@redhat.com> Message-ID: <87eb867b-18f6-6b06-7b6b-450391066b7f@redhat.com> On 12/12/2019 19:14, Andrew Haley wrote: > This assertion failure happens because load/store patterns in > aarch64.ad are incorrect. > . . . > Andrew Dinn will probably have a cow when he sees this patch. :-) I am currently suffering birth pangs. I will get back to you with a proper review asap. 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 From felix.yang at huawei.com Tue Dec 17 15:27:34 2019 From: felix.yang at huawei.com (felix.yang at huawei.com) Date: Tue, 17 Dec 2019 15:27:34 +0000 Subject: [aarch64-port-dev ] hg: aarch64-port/jdk8u-shenandoah/hotspot: 8135018: AARCH64: Missing memory barriers for CMS collector Message-ID: <201912171527.xBHFRZwA010910@aojmv0008.oracle.com> Changeset: 9495a9f80d99 Author: aph Date: 2015-09-24 12:04 +0200 URL: https://hg.openjdk.java.net/aarch64-port/jdk8u-shenandoah/hotspot/rev/9495a9f80d99 8135018: AARCH64: Missing memory barriers for CMS collector Summary: Add StoreStore barrier when CMS needs them Reviewed-by: tschatzl ! src/cpu/aarch64/vm/macroAssembler_aarch64.cpp ! src/cpu/aarch64/vm/stubGenerator_aarch64.cpp ! src/share/vm/c1/c1_LIRGenerator.cpp From adinn at redhat.com Tue Dec 17 16:39:41 2019 From: adinn at redhat.com (Andrew Dinn) Date: Tue, 17 Dec 2019 16:39:41 +0000 Subject: [aarch64-port-dev ] RFR: 8235385: AArch64: Crash on aarch64 JDK due to long offset In-Reply-To: <154c82af-865f-d250-395d-6cb9b41b2780@redhat.com> References: <154c82af-865f-d250-395d-6cb9b41b2780@redhat.com> Message-ID: On 12/12/2019 19:14, Andrew Haley wrote: > In a rather belt-and-braces way I've also added some code that fixes > up illegal addresses. I did consider removing it, but I left it in > because it doesn't hurt. If we ever do generate similar illegal > addresses, debug builds will assert. I'm not sure whether to keep this > or not. > > Andrew Dinn will probably have a cow when he sees this patch. :-) > > OK for HEAD? Well, that wasn't quite so painful as it sounded. Code Review: The repeated warning comments are a very good idea. I spotted two things in aarch64.ad: 1) Range rule: 7115 // Load Range 7116 instruct loadRange(iRegINoSp dst, memory8 mem) 7117 %{ 7118 match(Set dst (LoadRange mem)); 7119 7120 ins_cost(4 * INSN_COST); 7121 format %{ "ldrw $dst, $mem\t# range" %} 7122 7123 ins_encode(aarch64_enc_ldrw(dst, mem)); 7124 7125 ins_pipe(iload_reg_mem); 7126 %} I think that should be memory4? Also, should you maybe change the comment to // Load Range (32 bit signed) 2) Pop count rules The following rule uses 'memory4' to declare the memory op but passes 'sizeof (jfloat)' to the ldrs call. Would the latter not be better passed as 4? (n.b. you use the matching numeric literal as argument to loadStore in the encoding class definitions). 8161 instruct popCountI_mem(iRegINoSp dst, memory4 mem, vRegF tmp) %{8162 predicate(UsePopCountInstruction); 8163 match(Set dst (PopCountI (LoadI mem))); 8164 effect(TEMP tmp); 8165 ins_cost(INSN_COST * 13); 8166 8167 format %{ "ldrs $tmp, $mem\n\t" 8168 "cnt $tmp, $tmp\t# vector (8B)\n\t" 8169 "addv $tmp, $tmp\t# vector (8B)\n\t" 8170 "mov $dst, $tmp\t# vector (1D)" %} 8171 ins_encode %{ 8172 FloatRegister tmp_reg = as_FloatRegister($tmp$$reg); 8173 loadStore(MacroAssembler(&cbuf), &MacroAssembler::ldrs, tmp_reg, $mem->opcode(), 8174 as_Register($mem$$base), $mem$$index, $mem$$scale, $mem$$disp, sizeof (jfloat)); 8175 __ cnt($tmp$$FloatRegister, __ T8B, $tmp$$FloatRegister); 8176 __ addv($tmp$$FloatRegister, __ T8B, $tmp$$FloatRegister); 8177 __ mov($dst$$Register, $tmp$$FloatRegister, __ T1D, 0); 8178 %} . . . The same question applied for the next definition 8204 instruct popCountL_mem(iRegINoSp dst, memory8 mem, vRegD tmp) %{ . . . Yes, I too do not like the look of legitimize_address and it ought not to be necessary, given that the assert in debug mode ought to stop us hitting this in product mode. Still belt and braces is always a good thing so I'm happy for to stay (and do no harm). Testing: Was there a rationale for picking those specific offsets for the accesses? Anyway, I'm assuming the test didn't crash the JVM ;-) So, the only real issue is the size in the Range rule. I guess you didn't trigger a case where that mattered. Modulo that it is good to push. 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 From navy.xliu at gmail.com Tue Dec 17 18:26:53 2019 From: navy.xliu at gmail.com (Liu Xin) Date: Tue, 17 Dec 2019 10:26:53 -0800 Subject: [aarch64-port-dev ] hg: aarch64-port/jdk8u-shenandoah/hotspot: 8135018: AARCH64: Missing memory barriers for CMS collector In-Reply-To: <201912171527.xBHFRZwA010910@aojmv0008.oracle.com> References: <201912171527.xBHFRZwA010910@aojmv0008.oracle.com> Message-ID: hi, Felix, Thank you to review and sponsor it. thanks, --lx On Tue, Dec 17, 2019 at 7:27 AM wrote: > Changeset: 9495a9f80d99 > Author: aph > Date: 2015-09-24 12:04 +0200 > URL: > https://hg.openjdk.java.net/aarch64-port/jdk8u-shenandoah/hotspot/rev/9495a9f80d99 > > 8135018: AARCH64: Missing memory barriers for CMS collector > Summary: Add StoreStore barrier when CMS needs them > Reviewed-by: tschatzl > > ! src/cpu/aarch64/vm/macroAssembler_aarch64.cpp > ! src/cpu/aarch64/vm/stubGenerator_aarch64.cpp > ! src/share/vm/c1/c1_LIRGenerator.cpp > > From hohensee at amazon.com Tue Dec 17 19:30:45 2019 From: hohensee at amazon.com (Hohensee, Paul) Date: Tue, 17 Dec 2019 19:30:45 +0000 Subject: [aarch64-port-dev ] hg: aarch64-port/jdk8u-shenandoah/hotspot: 8135018: AARCH64: Missing memory barriers for CMS collector In-Reply-To: References: <201912171527.xBHFRZwA010910@aojmv0008.oracle.com> Message-ID: Hi, Felix, I can't find a JBS backport issue for this patch. Is one needed? If so, I can create cobble one together. Thanks, Paul ?On 12/17/19, 10:28 AM, "aarch64-port-dev on behalf of Liu Xin" wrote: hi, Felix, Thank you to review and sponsor it. thanks, --lx On Tue, Dec 17, 2019 at 7:27 AM wrote: > Changeset: 9495a9f80d99 > Author: aph > Date: 2015-09-24 12:04 +0200 > URL: > https://hg.openjdk.java.net/aarch64-port/jdk8u-shenandoah/hotspot/rev/9495a9f80d99 > > 8135018: AARCH64: Missing memory barriers for CMS collector > Summary: Add StoreStore barrier when CMS needs them > Reviewed-by: tschatzl > > ! src/cpu/aarch64/vm/macroAssembler_aarch64.cpp > ! src/cpu/aarch64/vm/stubGenerator_aarch64.cpp > ! src/share/vm/c1/c1_LIRGenerator.cpp > > From felix.yang at huawei.com Wed Dec 18 01:32:08 2019 From: felix.yang at huawei.com (Yangfei (Felix)) Date: Wed, 18 Dec 2019 01:32:08 +0000 Subject: [aarch64-port-dev ] hg: aarch64-port/jdk8u-shenandoah/hotspot: 8135018: AARCH64: Missing memory barriers for CMS collector In-Reply-To: References: <201912171527.xBHFRZwA010910@aojmv0008.oracle.com> Message-ID: Hi Paul, I was assuming that is needed when the jdk8u aarch64 repo is merged to the main upstream repository. Thanks, Felix > > Hi, Felix, > > I can't find a JBS backport issue for this patch. Is one needed? If so, I can create > cobble one together. > > Thanks, > Paul From ci_notify at linaro.org Wed Dec 18 13:03:34 2019 From: ci_notify at linaro.org (ci_notify at linaro.org) Date: Wed, 18 Dec 2019 13:03:34 +0000 (UTC) Subject: [aarch64-port-dev ] JTREG, JCStress, SPECjbb2015 and Hadoop/Terasort results for OpenJDK 11u on AArch64 Message-ID: <453073120.5489.1576674215693.JavaMail.javamailuser@localhost> This is a summary of the JTREG test results =========================================== The build and test results are cycled every 15 days. For detailed information on the test output please refer to: http://openjdk.linaro.org/jdk11u/openjdk-jtreg-nightly-tests/summary/2019/351/summary.html ------------------------------------------------------------------------------- release/hotspot ------------------------------------------------------------------------------- Build 0: aarch64/2019/sep/04 pass: 5,764; fail: 2 Build 1: aarch64/2019/sep/05 pass: 5,764; fail: 2 Build 2: aarch64/2019/sep/10 pass: 5,764; fail: 2 Build 3: aarch64/2019/sep/17 pass: 5,763; fail: 3 Build 4: aarch64/2019/sep/21 pass: 5,764; fail: 2 Build 5: aarch64/2019/oct/04 pass: 5,764; fail: 2 Build 6: aarch64/2019/oct/17 pass: 5,764; fail: 2 Build 7: aarch64/2019/oct/31 pass: 5,784; fail: 1 Build 8: aarch64/2019/nov/09 pass: 5,773; fail: 3 Build 9: aarch64/2019/nov/16 pass: 5,775; fail: 1 Build 10: aarch64/2019/nov/21 pass: 5,775; fail: 1 Build 11: aarch64/2019/dec/05 pass: 5,775; fail: 1 Build 12: aarch64/2019/dec/08 pass: 5,775; fail: 1 Build 13: aarch64/2019/dec/14 pass: 5,775; fail: 1 Build 14: aarch64/2019/dec/17 pass: 5,775; fail: 1 ------------------------------------------------------------------------------- release/jdk ------------------------------------------------------------------------------- Build 0: aarch64/2019/sep/04 pass: 8,483; fail: 465; error: 10 Build 1: aarch64/2019/sep/05 pass: 8,465; fail: 479; error: 14 Build 2: aarch64/2019/sep/10 pass: 8,444; fail: 500; error: 14 Build 3: aarch64/2019/sep/17 pass: 8,462; fail: 482; error: 12 Build 4: aarch64/2019/sep/21 pass: 8,467; fail: 478; error: 13 Build 5: aarch64/2019/oct/04 pass: 8,444; fail: 498; error: 16 Build 6: aarch64/2019/oct/17 pass: 8,452; fail: 493; error: 16 Build 7: aarch64/2019/oct/31 pass: 8,468; fail: 490; error: 14 Build 8: aarch64/2019/nov/09 pass: 8,487; fail: 470; error: 16 Build 9: aarch64/2019/nov/16 pass: 8,475; fail: 484; error: 15 Build 10: aarch64/2019/nov/21 pass: 8,489; fail: 497; error: 13 Build 11: aarch64/2019/dec/05 pass: 8,492; fail: 501; error: 11 Build 12: aarch64/2019/dec/08 pass: 8,482; fail: 505; error: 17 Build 13: aarch64/2019/dec/14 pass: 8,512; fail: 481; error: 12 Build 14: aarch64/2019/dec/17 pass: 8,485; fail: 505; error: 15 3 fatal errors were detected; please follow the link above for more detail. ------------------------------------------------------------------------------- release/langtools ------------------------------------------------------------------------------- Build 0: aarch64/2019/sep/04 pass: 3,910 Build 1: aarch64/2019/sep/05 pass: 3,910 Build 2: aarch64/2019/sep/10 pass: 3,910 Build 3: aarch64/2019/sep/17 pass: 3,910 Build 4: aarch64/2019/sep/21 pass: 3,910 Build 5: aarch64/2019/oct/04 pass: 3,910 Build 6: aarch64/2019/oct/17 pass: 3,910 Build 7: aarch64/2019/oct/31 pass: 3,910 Build 8: aarch64/2019/nov/09 pass: 3,910 Build 9: aarch64/2019/nov/16 pass: 3,910 Build 10: aarch64/2019/nov/21 pass: 3,910 Build 11: aarch64/2019/dec/05 pass: 3,910 Build 12: aarch64/2019/dec/08 pass: 3,910 Build 13: aarch64/2019/dec/14 pass: 3,910 Build 14: aarch64/2019/dec/17 pass: 3,910 Previous results can be found here: http://openjdk.linaro.org/jdk11u/openjdk-jtreg-nightly-tests/index.html SPECjbb2015 composite regression test completed =============================================== This test measures the relative performance of the server compiler running the SPECjbb2015 composite tests and compares the performance against the baseline performance of the server compiler taken on 2016-11-21. In accordance with [1], the SPECjbb2015 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): 7.46x Relative performance: Server critical-jOPS (nc): 8.18x Details of the test setup and historical results may be found here: http://openjdk.linaro.org/jdk11u/SPECjbb2015-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 server compiler on 2014-04-01. Relative performance: Zero: 1.0, Server: 210.67 Server 210.67 / Server 2014-04-01 (71.00): 2.97x Details of the test setup and historical results may be found here: http://openjdk.linaro.org/jdk11u/hadoop-terasort-benchmark-results/ This is a summary of the jcstress test results ============================================== The build and test results are cycled every 15 days. 2019-09-05 pass rate: 10489/10489, results: http://openjdk.linaro.org/jdk11u/jcstress-nightly-runs/2019/247/results/ 2019-09-07 pass rate: 10489/10489, results: http://openjdk.linaro.org/jdk11u/jcstress-nightly-runs/2019/248/results/ 2019-09-11 pass rate: 10489/10489, results: http://openjdk.linaro.org/jdk11u/jcstress-nightly-runs/2019/253/results/ 2019-09-18 pass rate: 10489/10489, results: http://openjdk.linaro.org/jdk11u/jcstress-nightly-runs/2019/260/results/ 2019-09-22 pass rate: 10489/10489, results: http://openjdk.linaro.org/jdk11u/jcstress-nightly-runs/2019/264/results/ 2019-10-05 pass rate: 10489/10489, results: http://openjdk.linaro.org/jdk11u/jcstress-nightly-runs/2019/277/results/ 2019-10-18 pass rate: 10489/10489, results: http://openjdk.linaro.org/jdk11u/jcstress-nightly-runs/2019/290/results/ 2019-11-01 pass rate: 10489/10489, results: http://openjdk.linaro.org/jdk11u/jcstress-nightly-runs/2019/304/results/ 2019-11-10 pass rate: 10490/10490, results: http://openjdk.linaro.org/jdk11u/jcstress-nightly-runs/2019/313/results/ 2019-11-17 pass rate: 10490/10490, results: http://openjdk.linaro.org/jdk11u/jcstress-nightly-runs/2019/320/results/ 2019-11-22 pass rate: 10490/10490, results: http://openjdk.linaro.org/jdk11u/jcstress-nightly-runs/2019/325/results/ 2019-12-07 pass rate: 10490/10490, results: http://openjdk.linaro.org/jdk11u/jcstress-nightly-runs/2019/339/results/ 2019-12-09 pass rate: 10490/10490, results: http://openjdk.linaro.org/jdk11u/jcstress-nightly-runs/2019/342/results/ 2019-12-15 pass rate: 10490/10490, results: http://openjdk.linaro.org/jdk11u/jcstress-nightly-runs/2019/348/results/ 2019-12-18 pass rate: 10490/10490, results: http://openjdk.linaro.org/jdk11u/jcstress-nightly-runs/2019/351/results/ For detailed information on the test output please refer to: http://openjdk.linaro.org/jdk11u/jcstress-nightly-runs/ From ci_notify at linaro.org Wed Dec 18 13:05:56 2019 From: ci_notify at linaro.org (ci_notify at linaro.org) Date: Wed, 18 Dec 2019 13:05:56 +0000 (UTC) Subject: [aarch64-port-dev ] JTREG, JCStress, SPECjbb2015 and Hadoop/Terasort results for OpenJDK 8u on AArch64 Message-ID: <1693689119.5491.1576674356923.JavaMail.javamailuser@localhost> This is a summary of the JTREG test results =========================================== The build and test results are cycled every 15 days. For detailed information on the test output please refer to: http://openjdk.linaro.org/jdk8u/openjdk-jtreg-nightly-tests/summary/2019/351/summary.html ------------------------------------------------------------------------------- release/hotspot ------------------------------------------------------------------------------- Build 0: aarch64/2019/aug/01 pass: 800; fail: 26; error: 12 Build 1: aarch64/2019/aug/04 pass: 808; fail: 30; error: 2 Build 2: aarch64/2019/aug/06 pass: 799; fail: 29; error: 12 Build 3: aarch64/2019/aug/08 pass: 830; fail: 9; error: 1 Build 4: aarch64/2019/aug/11 pass: 825; fail: 14; error: 1 Build 5: aarch64/2019/aug/13 pass: 830; fail: 9; error: 1 Build 6: aarch64/2019/aug/15 pass: 837; fail: 9; error: 1 Build 7: aarch64/2019/aug/17 pass: 837; fail: 9; error: 1 Build 8: aarch64/2019/aug/22 pass: 837; fail: 9; error: 1 Build 9: aarch64/2019/sep/10 pass: 838; fail: 13; error: 1 Build 10: aarch64/2019/sep/21 pass: 838; fail: 13; error: 1 Build 11: aarch64/2019/nov/02 pass: 843; fail: 9; error: 1 Build 12: aarch64/2019/nov/14 pass: 843; fail: 9; error: 1 Build 13: aarch64/2019/dec/16 pass: 843; fail: 10; error: 1 Build 14: aarch64/2019/dec/17 pass: 846; fail: 10; error: 2 ------------------------------------------------------------------------------- release/jdk ------------------------------------------------------------------------------- Build 0: aarch64/2019/aug/01 pass: 5,945; fail: 271; error: 24 Build 1: aarch64/2019/aug/04 pass: 5,949; fail: 270; error: 24 Build 2: aarch64/2019/aug/06 pass: 5,945; fail: 275; error: 23 Build 3: aarch64/2019/aug/08 pass: 5,953; fail: 267; error: 23 Build 4: aarch64/2019/aug/11 pass: 5,947; fail: 272; error: 25 Build 5: aarch64/2019/aug/13 pass: 5,962; fail: 258; error: 24 Build 6: aarch64/2019/aug/15 pass: 5,955; fail: 266; error: 23 Build 7: aarch64/2019/aug/17 pass: 5,951; fail: 269; error: 24 Build 8: aarch64/2019/aug/22 pass: 5,945; fail: 279; error: 20 Build 9: aarch64/2019/sep/10 pass: 5,951; fail: 273; error: 23 Build 10: aarch64/2019/sep/21 pass: 5,964; fail: 261; error: 22 Build 11: aarch64/2019/nov/02 pass: 5,956; fail: 278; error: 18 Build 12: aarch64/2019/nov/14 pass: 5,956; fail: 275; error: 21 Build 13: aarch64/2019/dec/16 pass: 5,964; fail: 267; error: 21 Build 14: aarch64/2019/dec/17 pass: 5,963; fail: 267; error: 22 1 fatal errors were detected; please follow the link above for more detail. ------------------------------------------------------------------------------- release/langtools ------------------------------------------------------------------------------- Build 0: aarch64/2019/aug/01 pass: 3,116; fail: 2 Build 1: aarch64/2019/aug/04 pass: 3,116; fail: 2 Build 2: aarch64/2019/aug/06 pass: 3,116; fail: 2 Build 3: aarch64/2019/aug/08 pass: 3,116; fail: 2 Build 4: aarch64/2019/aug/11 pass: 3,116; fail: 2 Build 5: aarch64/2019/aug/13 pass: 3,116; fail: 2 Build 6: aarch64/2019/aug/15 pass: 3,116; fail: 2 Build 7: aarch64/2019/aug/17 pass: 3,116; fail: 2 Build 8: aarch64/2019/aug/22 pass: 3,116; fail: 2 Build 9: aarch64/2019/sep/10 pass: 3,116; fail: 2 Build 10: aarch64/2019/sep/21 pass: 3,116; fail: 2 Build 11: aarch64/2019/nov/02 pass: 3,116; fail: 2 Build 12: aarch64/2019/nov/14 pass: 3,116; fail: 2 Build 13: aarch64/2019/dec/16 pass: 3,116; fail: 2 Build 14: aarch64/2019/dec/17 pass: 3,117; fail: 2 Previous results can be found here: http://openjdk.linaro.org/jdk8u/openjdk-jtreg-nightly-tests/index.html SPECjbb2015 composite regression test completed =============================================== This test measures the relative performance of the server compiler running the SPECjbb2015 composite tests and compares the performance against the baseline performance of the server compiler taken on 2016-11-21. In accordance with [1], the SPECjbb2015 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): 6.73x Relative performance: Server critical-jOPS (nc): 8.44x Details of the test setup and historical results may be found here: http://openjdk.linaro.org/jdk8u/SPECjbb2015-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 server compiler on 2014-04-01. Relative performance: Zero: 1.0, Server: 176.44 Server 176.44 / Server 2014-04-01 (71.00): 2.49x Details of the test setup and historical results may be found here: http://openjdk.linaro.org/jdk8u/hadoop-terasort-benchmark-results/ This is a summary of the jcstress test results ============================================== The build and test results are cycled every 15 days. 2019-08-02 pass rate: 8229/8229, results: http://openjdk.linaro.org/jdk8u/jcstress-nightly-runs/2019/213/results/ 2019-08-05 pass rate: 8229/8229, results: http://openjdk.linaro.org/jdk8u/jcstress-nightly-runs/2019/216/results/ 2019-08-07 pass rate: 8229/8229, results: http://openjdk.linaro.org/jdk8u/jcstress-nightly-runs/2019/218/results/ 2019-08-09 pass rate: 8229/8229, results: http://openjdk.linaro.org/jdk8u/jcstress-nightly-runs/2019/220/results/ 2019-08-12 pass rate: 8230/8230, results: http://openjdk.linaro.org/jdk8u/jcstress-nightly-runs/2019/223/results/ 2019-08-13 pass rate: 8230/8230, results: http://openjdk.linaro.org/jdk8u/jcstress-nightly-runs/2019/225/results/ 2019-08-16 pass rate: 8230/8230, results: http://openjdk.linaro.org/jdk8u/jcstress-nightly-runs/2019/227/results/ 2019-08-17 pass rate: 8230/8230, results: http://openjdk.linaro.org/jdk8u/jcstress-nightly-runs/2019/229/results/ 2019-08-23 pass rate: 8230/8230, results: http://openjdk.linaro.org/jdk8u/jcstress-nightly-runs/2019/234/results/ 2019-09-11 pass rate: 8230/8230, results: http://openjdk.linaro.org/jdk8u/jcstress-nightly-runs/2019/253/results/ 2019-09-22 pass rate: 8230/8230, results: http://openjdk.linaro.org/jdk8u/jcstress-nightly-runs/2019/264/results/ 2019-11-02 pass rate: 8230/8230, results: http://openjdk.linaro.org/jdk8u/jcstress-nightly-runs/2019/306/results/ 2019-11-15 pass rate: 8231/8231, results: http://openjdk.linaro.org/jdk8u/jcstress-nightly-runs/2019/318/results/ 2019-12-16 pass rate: 8231/8231, results: http://openjdk.linaro.org/jdk8u/jcstress-nightly-runs/2019/350/results/ 2019-12-18 pass rate: 8231/8231, results: http://openjdk.linaro.org/jdk8u/jcstress-nightly-runs/2019/351/results/ For detailed information on the test output please refer to: http://openjdk.linaro.org/jdk8u/jcstress-nightly-runs/ From gnu.andrew at redhat.com Wed Dec 18 14:14:04 2019 From: gnu.andrew at redhat.com (Andrew John Hughes) Date: Wed, 18 Dec 2019 14:14:04 +0000 Subject: [aarch64-port-dev ] [RFR] [8u] 8u242-b02 & 8u242-b04 Upstream Sync Message-ID: <16cb5a5b-3106-0375-14dc-60f25619fe02@redhat.com> Webrevs: https://cr.openjdk.java.net/~andrew/shenandoah-8/u242-b04/ This includes both the b02 and b04 merges. I'm not aware of an easy way to split them using webrev. Merge changesets for each are below. b03 was empty, so can be ignored. Merge changesets for b02: http://cr.openjdk.java.net/~andrew/shenandoah-8/u242-b04/corba/merge-b02.changeset http://cr.openjdk.java.net/~andrew/shenandoah-8/u242-b04/jaxp/merge-b02.changeset http://cr.openjdk.java.net/~andrew/shenandoah-8/u242-b04/jaxws/merge-b02.changeset http://cr.openjdk.java.net/~andrew/shenandoah-8/u242-b04/jdk/merge-b02.changeset http://cr.openjdk.java.net/~andrew/shenandoah-8/u242-b04/hotspot/merge-b02.changeset http://cr.openjdk.java.net/~andrew/shenandoah-8/u242-b04/langtools/merge-b02.changeset http://cr.openjdk.java.net/~andrew/shenandoah-8/u242-b04/nashorn/merge-b02.changeset http://cr.openjdk.java.net/~andrew/shenandoah-8/u242-b04/root/merge-b02.changeset Merge changesets for b04: http://cr.openjdk.java.net/~andrew/shenandoah-8/u242-b04/corba/merge-b04.changeset http://cr.openjdk.java.net/~andrew/shenandoah-8/u242-b04/jaxp/merge-b04.changeset http://cr.openjdk.java.net/~andrew/shenandoah-8/u242-b04/jaxws/merge-b04.changeset http://cr.openjdk.java.net/~andrew/shenandoah-8/u242-b04/jdk/merge-b04.changeset http://cr.openjdk.java.net/~andrew/shenandoah-8/u242-b04/hotspot/merge-b04.changeset http://cr.openjdk.java.net/~andrew/shenandoah-8/u242-b04/langtools/merge-b04.changeset http://cr.openjdk.java.net/~andrew/shenandoah-8/u242-b04/nashorn/merge-b04.changeset http://cr.openjdk.java.net/~andrew/shenandoah-8/u242-b04/root/merge-b04.changeset Changes in aarch64-shenandoah-jdk8u242-b02: - S8057986: freetype code to get glyph outline does not handle initial control point properly - S8068736: Avoid synchronization on Executable/Field.declaredAnnotations - S8073347: javadoc of Formattable messed up by JDK-8019857 - S8206173: MallocSiteTable::initialize() doesn't take function descriptors into account - S8213568: Typo in java/awt/GraphicsEnvironment/LoadLock/GE_init5.java - S8218558: NMT stack traces in output should show mt component for virtual memory allocations - S8225101: Crash at sun.awt.X11.XlibWrapper.XkbGetUpdatedMap when change keybord map - S8228888: C2 compilation fails with assert "m has strange control" - S8229020: Failure on CPUs allowing loads reordering: assert(_tasks[t] == 1) failed: What else? - S8229169: False failure of GenericTaskQueue::pop_local on architectures with weak memory model - S8230363: C2: Let ConnectionGraph::not_global_escape(Node* n) return false if n is not in the CG - S8231887: ComodoCA.java fails because certificate was revoked - S8233839: aarch64: missing memory barrier in NewObjectArrayStub and NewTypeArrayStub Changes in aarch64-shenandoah-jdk8u242-b04: - S8048556: Unnecessary GCLocker-initiated young GCs - S8073108: Use x86 and SPARC CPU instructions for GHASH acceleration - S8130341: GHASH 32bit intrinsics has AEADBadTagException - S8139178: Wrong fontMetrics when printing in Landscape (OpenJDK) - S8146238: [macosx] Java2D Queue Flusher crash on OSX after switching between user accounts - S8196681: Java Access Bridge logging and debug flags dynamically controlled - S8204288: Matching the end of a string followed by an empty greedy regex and a word boundary fails - S8204290: Add check to limit number of capture groups - S8219914: Change the environment variable for Java Access Bridge logging to have a directory. - S8225505: ctrl-F1 does not show the tooltip of a menu item (JMenuItems) Main issues of note: - 8233839 is already upstream: https://hg.openjdk.java.net/aarch64-port/jdk8u-shenandoah/hotspot/rev/09d4b646f756 - There is an AArch64 part of JDK-8073108 which had to be omitted upstream. Martin Balao will post this for inclusion here once this is pushed. diffstats for b02: diffstat for root (b02) b/.hgtags | 1 + 1 file changed, 1 insertion(+) diffstat for corba (b02) b/.hgtags | 1 + 1 file changed, 1 insertion(+) diffstat for jaxp (b02) b/.hgtags | 1 + 1 file changed, 1 insertion(+) diffstat for jaxws (b02) b/.hgtags | 1 + 1 file changed, 1 insertion(+) diffstat for langtools (b02) b/.hgtags | 1 + 1 file changed, 1 insertion(+) diffstat for nashorn (b02) b/.hgtags | 1 + 1 file changed, 1 insertion(+) diffstat for jdk (b02) b/.hgtags | 1 b/src/share/classes/java/lang/reflect/Executable.java | 35 b/src/share/classes/java/lang/reflect/Field.java | 33 b/src/share/classes/java/util/Formattable.java | 10 b/src/share/native/sun/font/freetypeScaler.c | 130 +- b/src/solaris/classes/sun/awt/X11/XToolkit.java | 18 b/test/java/awt/GraphicsEnvironment/LoadLock/GE_init5.java | 4 b/test/java/awt/font/GlyphVector/GlyphVectorOutline.java | 91 + b/test/security/infra/java/security/cert/CertPathValidator/certification/ComodoCA.java | 504 +++++----- 9 files changed, 488 insertions(+), 338 deletions(-) diffstat for hotspot (b02) b/.hgtags | 1 b/src/share/vm/opto/escape.cpp | 3 + b/src/share/vm/opto/loopopts.cpp | 2 b/src/share/vm/services/allocationSite.hpp | 5 +- b/src/share/vm/services/mallocSiteTable.cpp | 16 +++++-- b/src/share/vm/services/mallocSiteTable.hpp | 8 --- b/src/share/vm/services/memBaseline.cpp | 6 +- b/src/share/vm/services/memReporter.cpp | 29 ++++++++----- b/src/share/vm/services/memReporter.hpp | 2 b/src/share/vm/services/virtualMemoryTracker.hpp | 4 - b/src/share/vm/utilities/macros.hpp | 8 +++ b/src/share/vm/utilities/taskqueue.hpp | 5 ++ b/src/share/vm/utilities/workgroup.cpp | 1 b/test/compiler/loopopts/StrangeControl.jasm | 48 ++++++++++++++++++++++ b/test/compiler/loopopts/TestStrangeControl.java | 49 +++++++++++++++++++++++ 15 files changed, 157 insertions(+), 30 deletions(-) diffstats for b04: diffstat for root (b04) b/.hgtags | 2 ++ 1 file changed, 2 insertions(+) diffstat for corba (b04) b/.hgtags | 2 ++ 1 file changed, 2 insertions(+) diffstat for jaxp (b04) b/.hgtags | 2 ++ 1 file changed, 2 insertions(+) diffstat for jaxws (b04) b/.hgtags | 2 ++ 1 file changed, 2 insertions(+) diffstat for langtools (b04) b/.hgtags | 2 ++ 1 file changed, 2 insertions(+) diffstat for nashorn (b04) b/.hgtags | 2 b/src/jdk/nashorn/internal/runtime/regexp/joni/ByteCodeMachine.java | 2 b/src/jdk/nashorn/internal/runtime/regexp/joni/Config.java | 1 b/src/jdk/nashorn/internal/runtime/regexp/joni/ScanEnvironment.java | 3 b/src/jdk/nashorn/internal/runtime/regexp/joni/exception/ErrorMessages.java | 1 b/test/script/basic/JDK-8204288.js | 35 ++++++++ b/test/script/basic/JDK-8204290.js | 40 ++++++++++ 7 files changed, 82 insertions(+), 2 deletions(-) diffstat for jdk (b04) b/.hgtags | 2 b/src/macosx/classes/sun/java2d/opengl/CGLSurfaceData.java | 11 b/src/macosx/native/sun/java2d/opengl/CGLSurfaceData.m | 41 b/src/share/classes/com/sun/crypto/provider/GHASH.java | 103 - b/src/share/classes/javax/swing/ToolTipManager.java | 49 b/src/share/classes/sun/java2d/opengl/OGLSurfaceData.java | 9 b/src/share/native/sun/font/freetypeScaler.c | 18 b/src/share/native/sun/java2d/opengl/OGLSurfaceData.c | 12 b/src/share/native/sun/java2d/opengl/OGLSurfaceData.h | 6 b/src/solaris/classes/sun/java2d/opengl/GLXSurfaceData.java | 5 b/src/solaris/native/sun/java2d/opengl/GLXSurfaceData.c | 54 b/src/windows/classes/com/sun/java/accessibility/AccessBridge.java | 405 ++-- b/src/windows/classes/sun/java2d/opengl/WGLSurfaceData.java | 6 b/src/windows/native/sun/bridge/AccessBridgeATInstance.cpp | 26 b/src/windows/native/sun/bridge/AccessBridgeDebug.cpp | 93 - b/src/windows/native/sun/bridge/AccessBridgeDebug.h | 4 b/src/windows/native/sun/bridge/AccessBridgeEventHandler.cpp | 36 b/src/windows/native/sun/bridge/AccessBridgeJavaEntryPoints.cpp | 896 ++++------ b/src/windows/native/sun/bridge/AccessBridgeJavaVMInstance.cpp | 10 b/src/windows/native/sun/bridge/AccessBridgeMessageQueue.cpp | 20 b/src/windows/native/sun/bridge/JavaAccessBridge.cpp | 743 ++++---- b/src/windows/native/sun/bridge/WinAccessBridge.cpp | 542 +++--- b/src/windows/native/sun/java2d/opengl/WGLSurfaceData.c | 52 b/test/com/sun/crypto/provider/Cipher/AES/TestGHASH.java | 92 - b/test/java/awt/font/Rotate/RotatedFontMetricsTest.java | 79 b/test/javax/swing/ToolTipManager/JMenuItemToolTipKeyBindingsTest/JMenuItemToolTipKeyBindingsTest.java | 144 + 26 files changed, 1919 insertions(+), 1539 deletions(-) diffstat for hotspot (b04) b/.hgtags | 2 b/src/cpu/ppc/vm/vm_version_ppc.cpp | 5 b/src/cpu/sparc/vm/assembler_sparc.hpp | 8 b/src/cpu/sparc/vm/stubGenerator_sparc.cpp | 128 ++++ b/src/cpu/sparc/vm/vm_version_sparc.cpp | 11 b/src/cpu/x86/vm/assembler_x86.cpp | 9 b/src/cpu/x86/vm/assembler_x86.hpp | 2 b/src/cpu/x86/vm/stubGenerator_x86_32.cpp | 170 +++++ b/src/cpu/x86/vm/stubGenerator_x86_64.cpp | 176 ++++++ b/src/cpu/x86/vm/stubRoutines_x86.cpp | 4 b/src/cpu/x86/vm/stubRoutines_x86.hpp | 7 b/src/cpu/x86/vm/vm_version_x86.cpp | 11 b/src/share/vm/classfile/vmSymbols.hpp | 6 b/src/share/vm/gc_implementation/g1/g1CollectedHeap.cpp | 6 b/src/share/vm/gc_implementation/parallelScavenge/parallelScavengeHeap.cpp | 4 b/src/share/vm/gc_implementation/parallelScavenge/vmPSOperations.cpp | 10 b/src/share/vm/gc_implementation/shared/vmGCOperations.cpp | 13 b/src/share/vm/gc_implementation/shared/vmGCOperations.hpp | 4 b/src/share/vm/memory/gcLocker.cpp | 14 b/src/share/vm/memory/gcLocker.hpp | 8 b/src/share/vm/memory/genCollectedHeap.cpp | 24 b/src/share/vm/opto/escape.cpp | 1 b/src/share/vm/opto/library_call.cpp | 37 + b/src/share/vm/opto/runtime.cpp | 18 b/src/share/vm/opto/runtime.hpp | 2 b/src/share/vm/runtime/globals.hpp | 3 b/src/share/vm/runtime/stubRoutines.cpp | 1 b/src/share/vm/runtime/stubRoutines.hpp | 2 b/src/share/vm/runtime/vmStructs.cpp | 1 b/test/compiler/7184394/TestAESBase.java | 45 + b/test/compiler/7184394/TestAESDecode.java | 6 b/test/compiler/7184394/TestAESEncode.java | 8 b/test/compiler/7184394/TestAESMain.java | 7 b/test/gc/stress/gclocker/TestExcessGCLockerCollections.java | 285 ++++++++++ 34 files changed, 1006 insertions(+), 32 deletions(-) Both merges were successfully built on x86, x86_64, s390, s390x, ppc, ppc64, ppc64le & aarch64. Ok to push? Thanks, -- Andrew :) Senior Free Java Software Engineer Red Hat, Inc. (http://www.redhat.com) PGP Key: ed25519/0xCFDA0F9B35964222 (hkp://keys.gnupg.net) Fingerprint = 5132 579D D154 0ED2 3E04 C5A0 CFDA 0F9B 3596 4222 https://keybase.io/gnu_andrew From rkennke at redhat.com Wed Dec 18 14:23:29 2019 From: rkennke at redhat.com (Roman Kennke) Date: Wed, 18 Dec 2019 15:23:29 +0100 Subject: [aarch64-port-dev ] [RFR] [8u] 8u242-b02 & 8u242-b04 Upstream Sync In-Reply-To: <16cb5a5b-3106-0375-14dc-60f25619fe02@redhat.com> References: <16cb5a5b-3106-0375-14dc-60f25619fe02@redhat.com> Message-ID: <59729053-f4c1-c2de-a133-31b5f4bf5129@redhat.com> Hi Andrew, > Webrevs: https://cr.openjdk.java.net/~andrew/shenandoah-8/u242-b04/ > > This includes both the b02 and b04 merges. I'm not aware of an easy way > to split them using webrev. Merge changesets for each are below. > > b03 was empty, so can be ignored. > > Merge changesets for b02: > > http://cr.openjdk.java.net/~andrew/shenandoah-8/u242-b04/corba/merge-b02.changeset > http://cr.openjdk.java.net/~andrew/shenandoah-8/u242-b04/jaxp/merge-b02.changeset > http://cr.openjdk.java.net/~andrew/shenandoah-8/u242-b04/jaxws/merge-b02.changeset > http://cr.openjdk.java.net/~andrew/shenandoah-8/u242-b04/jdk/merge-b02.changeset > http://cr.openjdk.java.net/~andrew/shenandoah-8/u242-b04/hotspot/merge-b02.changeset > http://cr.openjdk.java.net/~andrew/shenandoah-8/u242-b04/langtools/merge-b02.changeset > http://cr.openjdk.java.net/~andrew/shenandoah-8/u242-b04/nashorn/merge-b02.changeset > http://cr.openjdk.java.net/~andrew/shenandoah-8/u242-b04/root/merge-b02.changeset > > Merge changesets for b04: > > http://cr.openjdk.java.net/~andrew/shenandoah-8/u242-b04/corba/merge-b04.changeset > http://cr.openjdk.java.net/~andrew/shenandoah-8/u242-b04/jaxp/merge-b04.changeset > http://cr.openjdk.java.net/~andrew/shenandoah-8/u242-b04/jaxws/merge-b04.changeset > http://cr.openjdk.java.net/~andrew/shenandoah-8/u242-b04/jdk/merge-b04.changeset > http://cr.openjdk.java.net/~andrew/shenandoah-8/u242-b04/hotspot/merge-b04.changeset > http://cr.openjdk.java.net/~andrew/shenandoah-8/u242-b04/langtools/merge-b04.changeset > http://cr.openjdk.java.net/~andrew/shenandoah-8/u242-b04/nashorn/merge-b04.changeset > http://cr.openjdk.java.net/~andrew/shenandoah-8/u242-b04/root/merge-b04.changeset > > Changes in aarch64-shenandoah-jdk8u242-b02: > - S8057986: freetype code to get glyph outline does not handle initial > control point properly > - S8068736: Avoid synchronization on Executable/Field.declaredAnnotations > - S8073347: javadoc of Formattable messed up by JDK-8019857 > - S8206173: MallocSiteTable::initialize() doesn't take function > descriptors into account > - S8213568: Typo in java/awt/GraphicsEnvironment/LoadLock/GE_init5.java > - S8218558: NMT stack traces in output should show mt component for > virtual memory allocations > - S8225101: Crash at sun.awt.X11.XlibWrapper.XkbGetUpdatedMap when > change keybord map > - S8228888: C2 compilation fails with assert "m has strange control" > - S8229020: Failure on CPUs allowing loads reordering: > assert(_tasks[t] == 1) failed: What else? > - S8229169: False failure of GenericTaskQueue::pop_local on > architectures with weak memory model > - S8230363: C2: Let ConnectionGraph::not_global_escape(Node* n) return > false if n is not in the CG > - S8231887: ComodoCA.java fails because certificate was revoked > - S8233839: aarch64: missing memory barrier in NewObjectArrayStub and > NewTypeArrayStub > > Changes in aarch64-shenandoah-jdk8u242-b04: > - S8048556: Unnecessary GCLocker-initiated young GCs > - S8073108: Use x86 and SPARC CPU instructions for GHASH acceleration > - S8130341: GHASH 32bit intrinsics has AEADBadTagException > - S8139178: Wrong fontMetrics when printing in Landscape (OpenJDK) > - S8146238: [macosx] Java2D Queue Flusher crash on OSX after switching > between user accounts > - S8196681: Java Access Bridge logging and debug flags dynamically > controlled > - S8204288: Matching the end of a string followed by an empty greedy > regex and a word boundary fails > - S8204290: Add check to limit number of capture groups > - S8219914: Change the environment variable for Java Access Bridge > logging to have a directory. > - S8225505: ctrl-F1 does not show the tooltip of a menu item (JMenuItems) > > Main issues of note: > - 8233839 is already upstream: > https://hg.openjdk.java.net/aarch64-port/jdk8u-shenandoah/hotspot/rev/09d4b646f756 > - There is an AArch64 part of JDK-8073108 which had to be omitted > upstream. Martin Balao will post this for inclusion here once this is > pushed. > > diffstats for b02: > > diffstat for root (b02) > b/.hgtags | 1 + > 1 file changed, 1 insertion(+) > > diffstat for corba (b02) > b/.hgtags | 1 + > 1 file changed, 1 insertion(+) > > diffstat for jaxp (b02) > b/.hgtags | 1 + > 1 file changed, 1 insertion(+) > > diffstat for jaxws (b02) > b/.hgtags | 1 + > 1 file changed, 1 insertion(+) > > diffstat for langtools (b02) > b/.hgtags | 1 + > 1 file changed, 1 insertion(+) > > diffstat for nashorn (b02) > b/.hgtags | 1 + > 1 file changed, 1 insertion(+) > > diffstat for jdk (b02) > b/.hgtags > | 1 > b/src/share/classes/java/lang/reflect/Executable.java > | 35 > b/src/share/classes/java/lang/reflect/Field.java > | 33 > b/src/share/classes/java/util/Formattable.java > | 10 > b/src/share/native/sun/font/freetypeScaler.c > | 130 +- > b/src/solaris/classes/sun/awt/X11/XToolkit.java > | 18 > b/test/java/awt/GraphicsEnvironment/LoadLock/GE_init5.java > | 4 > b/test/java/awt/font/GlyphVector/GlyphVectorOutline.java > | 91 + > b/test/security/infra/java/security/cert/CertPathValidator/certification/ComodoCA.java | 504 +++++----- > 9 files changed, 488 insertions(+), 338 deletions(-) > > diffstat for hotspot (b02) > b/.hgtags | 1 > b/src/share/vm/opto/escape.cpp | 3 + > b/src/share/vm/opto/loopopts.cpp | 2 > b/src/share/vm/services/allocationSite.hpp | 5 +- > b/src/share/vm/services/mallocSiteTable.cpp | 16 +++++-- > b/src/share/vm/services/mallocSiteTable.hpp | 8 --- > b/src/share/vm/services/memBaseline.cpp | 6 +- > b/src/share/vm/services/memReporter.cpp | 29 ++++++++----- > b/src/share/vm/services/memReporter.hpp | 2 > b/src/share/vm/services/virtualMemoryTracker.hpp | 4 - > b/src/share/vm/utilities/macros.hpp | 8 +++ > b/src/share/vm/utilities/taskqueue.hpp | 5 ++ > b/src/share/vm/utilities/workgroup.cpp | 1 > b/test/compiler/loopopts/StrangeControl.jasm | 48 > ++++++++++++++++++++++ > b/test/compiler/loopopts/TestStrangeControl.java | 49 > +++++++++++++++++++++++ > 15 files changed, 157 insertions(+), 30 deletions(-) > > diffstats for b04: > > diffstat for root (b04) > b/.hgtags | 2 ++ > 1 file changed, 2 insertions(+) > > diffstat for corba (b04) > b/.hgtags | 2 ++ > 1 file changed, 2 insertions(+) > > diffstat for jaxp (b04) > b/.hgtags | 2 ++ > 1 file changed, 2 insertions(+) > > diffstat for jaxws (b04) > b/.hgtags | 2 ++ > 1 file changed, 2 insertions(+) > > diffstat for langtools (b04) > b/.hgtags | 2 ++ > 1 file changed, 2 insertions(+) > > diffstat for nashorn (b04) > b/.hgtags > | 2 > b/src/jdk/nashorn/internal/runtime/regexp/joni/ByteCodeMachine.java > | 2 > b/src/jdk/nashorn/internal/runtime/regexp/joni/Config.java > | 1 > b/src/jdk/nashorn/internal/runtime/regexp/joni/ScanEnvironment.java > | 3 > b/src/jdk/nashorn/internal/runtime/regexp/joni/exception/ErrorMessages.java | 1 > b/test/script/basic/JDK-8204288.js > | 35 ++++++++ > b/test/script/basic/JDK-8204290.js > | 40 ++++++++++ > 7 files changed, 82 insertions(+), 2 deletions(-) > > diffstat for jdk (b04) > b/.hgtags > | 2 > b/src/macosx/classes/sun/java2d/opengl/CGLSurfaceData.java > | 11 > b/src/macosx/native/sun/java2d/opengl/CGLSurfaceData.m > | 41 > b/src/share/classes/com/sun/crypto/provider/GHASH.java > | 103 - > b/src/share/classes/javax/swing/ToolTipManager.java > | 49 > b/src/share/classes/sun/java2d/opengl/OGLSurfaceData.java > | 9 > b/src/share/native/sun/font/freetypeScaler.c > | 18 > b/src/share/native/sun/java2d/opengl/OGLSurfaceData.c > | 12 > b/src/share/native/sun/java2d/opengl/OGLSurfaceData.h > | 6 > b/src/solaris/classes/sun/java2d/opengl/GLXSurfaceData.java > | 5 > b/src/solaris/native/sun/java2d/opengl/GLXSurfaceData.c > | 54 > b/src/windows/classes/com/sun/java/accessibility/AccessBridge.java > | 405 ++-- > b/src/windows/classes/sun/java2d/opengl/WGLSurfaceData.java > | 6 > b/src/windows/native/sun/bridge/AccessBridgeATInstance.cpp > | 26 > b/src/windows/native/sun/bridge/AccessBridgeDebug.cpp > | 93 - > b/src/windows/native/sun/bridge/AccessBridgeDebug.h > | 4 > b/src/windows/native/sun/bridge/AccessBridgeEventHandler.cpp > | 36 > b/src/windows/native/sun/bridge/AccessBridgeJavaEntryPoints.cpp > | 896 ++++------ > b/src/windows/native/sun/bridge/AccessBridgeJavaVMInstance.cpp > | 10 > b/src/windows/native/sun/bridge/AccessBridgeMessageQueue.cpp > | 20 > b/src/windows/native/sun/bridge/JavaAccessBridge.cpp > | 743 ++++---- > b/src/windows/native/sun/bridge/WinAccessBridge.cpp > | 542 +++--- > b/src/windows/native/sun/java2d/opengl/WGLSurfaceData.c > | 52 > b/test/com/sun/crypto/provider/Cipher/AES/TestGHASH.java > | 92 - > b/test/java/awt/font/Rotate/RotatedFontMetricsTest.java > | 79 > b/test/javax/swing/ToolTipManager/JMenuItemToolTipKeyBindingsTest/JMenuItemToolTipKeyBindingsTest.java | 144 + > 26 files changed, 1919 insertions(+), 1539 deletions(-) > > diffstat for hotspot (b04) > b/.hgtags > | 2 > b/src/cpu/ppc/vm/vm_version_ppc.cpp > | 5 > b/src/cpu/sparc/vm/assembler_sparc.hpp > | 8 > b/src/cpu/sparc/vm/stubGenerator_sparc.cpp > | 128 ++++ > b/src/cpu/sparc/vm/vm_version_sparc.cpp > | 11 > b/src/cpu/x86/vm/assembler_x86.cpp > | 9 > b/src/cpu/x86/vm/assembler_x86.hpp > | 2 > b/src/cpu/x86/vm/stubGenerator_x86_32.cpp > | 170 +++++ > b/src/cpu/x86/vm/stubGenerator_x86_64.cpp > | 176 ++++++ > b/src/cpu/x86/vm/stubRoutines_x86.cpp > | 4 > b/src/cpu/x86/vm/stubRoutines_x86.hpp > | 7 > b/src/cpu/x86/vm/vm_version_x86.cpp > | 11 > b/src/share/vm/classfile/vmSymbols.hpp > | 6 > b/src/share/vm/gc_implementation/g1/g1CollectedHeap.cpp > | 6 > b/src/share/vm/gc_implementation/parallelScavenge/parallelScavengeHeap.cpp | 4 > b/src/share/vm/gc_implementation/parallelScavenge/vmPSOperations.cpp > | 10 > b/src/share/vm/gc_implementation/shared/vmGCOperations.cpp > | 13 > b/src/share/vm/gc_implementation/shared/vmGCOperations.hpp > | 4 > b/src/share/vm/memory/gcLocker.cpp > | 14 > b/src/share/vm/memory/gcLocker.hpp > | 8 > b/src/share/vm/memory/genCollectedHeap.cpp > | 24 > b/src/share/vm/opto/escape.cpp > | 1 > b/src/share/vm/opto/library_call.cpp > | 37 + > b/src/share/vm/opto/runtime.cpp > | 18 > b/src/share/vm/opto/runtime.hpp > | 2 > b/src/share/vm/runtime/globals.hpp > | 3 > b/src/share/vm/runtime/stubRoutines.cpp > | 1 > b/src/share/vm/runtime/stubRoutines.hpp > | 2 > b/src/share/vm/runtime/vmStructs.cpp > | 1 > b/test/compiler/7184394/TestAESBase.java > | 45 + > b/test/compiler/7184394/TestAESDecode.java > | 6 > b/test/compiler/7184394/TestAESEncode.java > | 8 > b/test/compiler/7184394/TestAESMain.java > | 7 > b/test/gc/stress/gclocker/TestExcessGCLockerCollections.java > | 285 ++++++++++ > 34 files changed, 1006 insertions(+), 32 deletions(-) > > Both merges were successfully built on x86, x86_64, s390, s390x, ppc, > ppc64, ppc64le & aarch64. > > Ok to push? Looks good! Thanks! Roman From navy.xliu at gmail.com Mon Dec 16 22:22:50 2019 From: navy.xliu at gmail.com (Liu Xin) Date: Mon, 16 Dec 2019 14:22:50 -0800 Subject: [aarch64-port-dev ] RFR 8135018: AARCH64: Missing memory barriers for CMS collector In-Reply-To: References: <2b433414-fab1-c63d-1e07-76ddd4abe298@redhat.com> <42729c1e-f90a-2a8d-cd48-c50e7a160245@redhat.com> <2e483546-f34f-3c96-a2aa-6d7b4fc47cc2@redhat.com> Message-ID: Hi, Reviewers, How about this Webrev? I modified as Felix's suggestion. https://cr.openjdk.java.net/~xliu/8135018/03/webrev/ Passed hotspot:tier1 and jcstress with CMS. I eyeballed the generated code. it inserts membar(StoreStore) correctly. 0x0000ffff80322f50: lsr x8, x0, #3 0x0000ffff80322f54: str w8, [x1, #12] 0x0000ffff80322f58: lsr x0, x1, #9 0x0000ffff80322f5c: dmb ishst 0x0000ffff80322f60: mov x1, #0xf000 // #61440 0x0000ffff80322f64: movk x1, #0x8a49, lsl #16 0x0000ffff80322f68: movk x1, #0xffff, lsl #32 0x0000ffff80322f6c: strb wzr, [x0, x1, lsl #0] ;*putfield arr ; - ByteTest::actor1 at 4 (line 5) thanks, --lx ; - ByteTest::actor1 at 4 (lin On Mon, Dec 16, 2019 at 3:54 AM Liu Xin wrote: > "store store barriers" > http://gee.cs.oswego.edu/dl/jmm/cookbook.html > > I think the JDK-8135018 inserts a membar(StoreStore) in the middle of > put_field and update_cardTable on purpose. it can guarantee memory orders > seen by Concurrent Mark Threads. > if you put the storestore membar after two stores, IMHO, the hazard is > still there. > > > On Mon, Dec 16, 2019 at 3:34 AM Liu Xin wrote: > >> hi, Felix, >> >> The original storestore appears right before strb. your >> membar(storeStore) is after strb. is it the same? >> if it's same, we can place membar out of if/else to dedup. >> >> >> diff --git a/src/hotspot/src/share/vm/c1/c1_LIRGenerator.cpp >> b/src/hotspot/src/share/vm/c1/c1_LIRGenerator.cpp >> index 19ec64d8..068f0797 100644 >> --- a/src/hotspot/src/share/vm/c1/c1_LIRGenerator.cpp >> +++ b/src/hotspot/src/share/vm/c1/c1_LIRGenerator.cpp >> @@ -1615,6 +1615,9 @@ void >> LIRGenerator::CardTableModRef_post_barrier(LIR_OprDesc* addr, LIR_OprDesc* >> new LIR_Address(tmp, load_constant(card_table_base), >> T_BYTE)); >> } >> + if (UseConcMarkSweepGC && CMSPrecleaningEnabled) { >> + __ membar_storestore(); >> + } >> #endif >> } >> >> On Mon, Dec 16, 2019 at 3:21 AM Yangfei (Felix) >> wrote: >> >>> Hi Liu Xin, >>> >>> Based on what Andrew said about UseCondCardMark, I agree with Martin >>> that we go with your new backport webrev for 8135018 first. >>> My only concern is that we changed to store >>> CardTableModRefBS::dirty_card_val() instead of constant zero to card_addr >>> in c1_LIRGenerator.cpp. >>> It looks to me unnecessary to add this change when you are adding the >>> missing memory bars. >>> So I suggest we do: >>> >>> diff -r 09d4b646f756 src/share/vm/c1/c1_LIRGenerator.cpp >>> --- a/src/share/vm/c1/c1_LIRGenerator.cpp Tue Nov 12 17:54:52 2019 >>> +0800 >>> +++ b/src/share/vm/c1/c1_LIRGenerator.cpp Mon Dec 16 19:17:51 2019 >>> +0800 >>> @@ -1622,10 +1622,16 @@ >>> if (can_inline_as_constant(card_table_base)) { >>> __ move(LIR_OprFact::intConst(0), >>> new LIR_Address(tmp, card_table_base->as_jint(), T_BYTE)); >>> + if (UseConcMarkSweepGC && CMSPrecleaningEnabled) { >>> + __ membar_storestore(); >>> + } >>> } else { >>> __ move(LIR_OprFact::intConst(0), >>> new LIR_Address(tmp, load_constant(card_table_base), >>> T_BYTE)); >>> + if (UseConcMarkSweepGC && CMSPrecleaningEnabled) { >>> + __ membar_storestore(); >>> + } >>> } >>> #endif >>> } >>> >>> >>> Thanks, >>> Felix >>> >>> > >>> > From: Liu Xin >>> > Sent: Montag, 16. Dezember 2019 10:48 >>> > To: Andrew Haley >>> > Cc: Doerr, Martin ; >>> > aarch64-port-dev at openjdk.java.net; Hohensee, Paul >>> > >>> > Subject: Re: RFR 8135018: AARCH64: Missing memory barriers for CMS >>> > collector >>> > >>> > Hi, Andrew and Felix, >>> > >>> > I did backport as Felix suggested. To get UseCondCardMark, we need to >>> > backport other 3 patches. >>> > >>> > hg qseries as follows ( applied in order) >>> > 8076987: https://cr.openjdk.java.net/~xliu/8076987/00/webrev/ >>> > 8078438: https://cr.openjdk.java.net/~xliu/8078438/00/webrev/ >>> > 8079315: https://cr.openjdk.java.net/~xliu/8079315/00/webrev/ >>> > 8135018: https://cr.openjdk.java.net/~xliu/8135018/02/webrev/ >>> > >>> > As Andrew pointed out, I also notice that it introduces a storeLoad >>> membar for >>> > interpreter if UseCondCardMark is on. >>> > The reason I didn't backport UseCondCardMark at first place because >>> it's off by >>> > default. I need to run all tests again with the new parameter >>> > -XX:+UseCondCardMark to validate it. Another reason is that all >>> performance >>> > evaluation was done on x86_64. >>> > It's really time consuming to evaluate performance impact on aarch64. >>> So I >>> > shortcut to fix my primary bug. >>> > >>> > Could you sponsor my previous webrev? >>> > https://cr.openjdk.java.net/~xliu/8135018/01/webrev/ >>> > >>> > It does have a conflict with c1_LIRGenerator.cpp. How about I send >>> another >>> > webrev to jdk8u and update it as well? >>> > >>> > thanks, >>> > --lx >>> > >>> > >>> > On Mon, Dec 16, 2019 at 1:00 AM Andrew Haley >>> > > wrote: >>> > On 12/14/19 4:47 AM, Liu Xin wrote: >>> > > I trace the feature UseCondCardMark. It was introduced by the >>> > > following changes. >>> > > https://bugs.openjdk.java.net/browse/JDK-8076987 C1 >>> > > https://bugs.openjdk.java.net/browse/JDK-8078438 interpreter >>> > > UseCondCardMark is only supported by C2 currently. >>> > >>> > UseCondCardMark was supposed to be a performance enhancement for very >>> > large multi-core systems, but we realized that it needed a StoreLoad >>> barrier. >>> > Because StoreLoad is so expensive there is no performance advantage, >>> > therefore as far as I can see the whole UseCondCardMark exercise is a >>> waste >>> > of time. There is no point back-porting changes to the interpreter and >>> C1. >>> > >>> > Unless someone does some performance measurements to prove that there >>> is >>> > some performance gain in C1 and the interpreter, UseCondCardMark >>> changes >>> > should not be back-ported. >>> > >>> > -- >>> > Andrew Haley (he/him) >>> > Java Platform Lead Engineer >>> > Red Hat UK Ltd. >>> https://keybase.io/andrewhaley >>> > EAC8 43EB D3EF DB98 CC77 2FAD A5CD 6035 332F A671 >>> >> From adinn at redhat.com Wed Dec 18 16:18:34 2019 From: adinn at redhat.com (Andrew Dinn) Date: Wed, 18 Dec 2019 16:18:34 +0000 Subject: [aarch64-port-dev ] RFR: 8229351: AArch64: Make the stub threshold of string_compare intrinsic tunable In-Reply-To: References: Message-ID: <43199499-782e-4747-1037-e02dbfc8f1c1@redhat.com> Hi Patrick, On 10/12/2019 05:49, Patrick Zhang OS wrote: > Please help review this patch (updated), thanks. > > JBS: https://bugs.openjdk.java.net/browse/JDK-8229351 > Webrev: http://cr.openjdk.java.net/~qpzhang/8229351/webrev.05 Thanks for splitting this bit of your patch out. The tests show a nice improvement and the patch is ok to push. 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 From hohensee at amazon.com Wed Dec 18 16:54:27 2019 From: hohensee at amazon.com (Hohensee, Paul) Date: Wed, 18 Dec 2019 16:54:27 +0000 Subject: [aarch64-port-dev ] hg: aarch64-port/jdk8u-shenandoah/hotspot: 8135018: AARCH64: Missing memory barriers for CMS collector In-Reply-To: References: <201912171527.xBHFRZwA010910@aojmv0008.oracle.com> Message-ID: <0C2748CA-2F7A-4B19-9684-07C4E8B5154E@amazon.com> Thanks for the explanation. I wasn't clear on how things work with the jdk8u-shenandoah repo. Paul ?On 12/17/19, 5:33 PM, "Yangfei (Felix)" wrote: Hi Paul, I was assuming that is needed when the jdk8u aarch64 repo is merged to the main upstream repository. Thanks, Felix > > Hi, Felix, > > I can't find a JBS backport issue for this patch. Is one needed? If so, I can create > cobble one together. > > Thanks, > Paul From adinn at redhat.com Wed Dec 18 17:27:32 2019 From: adinn at redhat.com (Andrew Dinn) Date: Wed, 18 Dec 2019 17:27:32 +0000 Subject: [aarch64-port-dev ] RFR (trivial): 8234228: AArch64: Clean up redundant temp vars in generate_compare_long_string_different_encoding In-Reply-To: References: Message-ID: <761841e0-995d-ceef-50e0-0d5c72beb77e@redhat.com> Hi Patrick, On 10/12/2019 05:43, Patrick Zhang OS wrote: > Could anyone help review this patch, thanks. > > JBS: https://bugs.openjdk.java.net/browse/JDK-8234228 > Webrev: http://cr.openjdk.java.net/~qpzhang/8234228/webrev.01 Thank you. This patch is good and ok to push. It took me quite a while to figure out that this was a trivial patch because the code is *abysmally* written and *even more* badly explained. The worst aspect of it is the register naming which is extremely misleading. However, it is terrible in many other respects. I think the code really needs a respray and, perhaps, some reorganization to make it clearer what is going on. regards, Andrew Dinn ----------- From patrick at os.amperecomputing.com Thu Dec 19 04:21:03 2019 From: patrick at os.amperecomputing.com (Patrick Zhang OS) Date: Thu, 19 Dec 2019 04:21:03 +0000 Subject: [aarch64-port-dev ] RFR (trivial): 8234228: AArch64: Clean up redundant temp vars in generate_compare_long_string_different_encoding In-Reply-To: <761841e0-995d-ceef-50e0-0d5c72beb77e@redhat.com> References: <761841e0-995d-ceef-50e0-0d5c72beb77e@redhat.com> Message-ID: Thanks Andrew, I uploaded a new webrev: http://cr.openjdk.java.net/~qpzhang/8234228/webrev.02. Nothing changed in code, I rebased it on the latest tip, checked building, and updated the reviewer list. Could you please help sponsor and push it? Thanks in advance. With regards to the code refine for these intrinsics, Dmitrij had a nice patch for refactoring, as well as the inline document [1]. I believe the functions can be improved much once his code changes get pushed in future. FYI. [1] http://cr.openjdk.java.net/~dpochepk/8218748/webrev.02/src/hotspot/cpu/aarch64/stubGenerator_aarch64.cpp.sdiff.html Regards Patrick -----Original Message----- From: Andrew Dinn Sent: Thursday, December 19, 2019 1:28 AM To: Patrick Zhang OS ; aarch64-port-dev at openjdk.java.net Subject: Re: [aarch64-port-dev ] RFR (trivial): 8234228: AArch64: Clean up redundant temp vars in generate_compare_long_string_different_encoding Hi Patrick, On 10/12/2019 05:43, Patrick Zhang OS wrote: > Could anyone help review this patch, thanks. > > JBS: https://bugs.openjdk.java.net/browse/JDK-8234228 > Webrev: http://cr.openjdk.java.net/~qpzhang/8234228/webrev.01 Thank you. This patch is good and ok to push. It took me quite a while to figure out that this was a trivial patch because the code is *abysmally* written and *even more* badly explained. The worst aspect of it is the register naming which is extremely misleading. However, it is terrible in many other respects. I think the code really needs a respray and, perhaps, some reorganization to make it clearer what is going on. regards, Andrew Dinn ----------- From Pengfei.Li at arm.com Thu Dec 19 07:42:38 2019 From: Pengfei.Li at arm.com (Pengfei Li) Date: Thu, 19 Dec 2019 07:42:38 +0000 Subject: [aarch64-port-dev ] Question: JNI critical native support is not fully implemented for AArch64? Message-ID: Hi, JDK-8200388[1] reports an issue that JNI critical native support is not implemented on AArch64. I searched the code and found this feature has been supported by all other platforms OpenJDK has. I also found in the AArch64 version of SharedRuntime::generate_native_wrapper(), the main logic for generating critical native wrapper code is already there but some necessary helper classes/methods are missing - marked as "Unimplemented()" by adinn many years ago - including these below. - static void check_needs_gc_for_critical_native() - static void unpack_array_argument() - class ComputeMoveOrder: public StackObj {} While I also see someone saying that this feature is designed for internal use only and there is no public specification for it[2]. And I don't know if there is any real workload currently using it. So could anyone tell me if "Critical Natives" is a sort of "public feature" of OpenJDK? And is there much value to complement the implementation for AArch64? [1] https://bugs.openjdk.java.net/browse/JDK-8200388 [2] https://stackoverflow.com/questions/36298111/is-it-possible-to-use-sun-misc-unsafe-to-call-c-functions-without-jni -- Thanks, Pengfei From patrick at os.amperecomputing.com Thu Dec 19 07:51:50 2019 From: patrick at os.amperecomputing.com (Patrick Zhang OS) Date: Thu, 19 Dec 2019 07:51:50 +0000 Subject: [aarch64-port-dev ] RFR: 8229351: AArch64: Make the stub threshold of string_compare intrinsic tunable In-Reply-To: <43199499-782e-4747-1037-e02dbfc8f1c1@redhat.com> References: <43199499-782e-4747-1037-e02dbfc8f1c1@redhat.com> Message-ID: Appreciate your reviews. I updated the list of reviewers accordingly. http://cr.openjdk.java.net/~qpzhang/8229351/webrev.06/jdk.changeset If no further comments, could any committer please help push it? Thanks. Regards Patrick -----Original Message----- From: Andrew Dinn Sent: Thursday, December 19, 2019 12:19 AM To: Patrick Zhang OS ; Andrew Haley ; aarch64-port-dev at openjdk.java.net Subject: Re: [aarch64-port-dev ] RFR: 8229351: AArch64: Make the stub threshold of string_compare intrinsic tunable Hi Patrick, On 10/12/2019 05:49, Patrick Zhang OS wrote: > Please help review this patch (updated), thanks. > > JBS: https://bugs.openjdk.java.net/browse/JDK-8229351 > Webrev: http://cr.openjdk.java.net/~qpzhang/8229351/webrev.05 Thanks for splitting this bit of your patch out. The tests show a nice improvement and the patch is ok to push. 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 From aph at redhat.com Thu Dec 19 10:10:37 2019 From: aph at redhat.com (Andrew Haley) Date: Thu, 19 Dec 2019 11:10:37 +0100 Subject: [aarch64-port-dev ] Question: JNI critical native support is not fully implemented for AArch64? In-Reply-To: References: Message-ID: <19c47e46-c0b3-ef63-879b-b736c210e1ad@redhat.com> On 12/19/19 7:42 AM, Pengfei Li wrote: > While I also see someone saying that this feature is designed for internal use only and there is no public specification for it[2]. And I don't know if there is any real workload currently using it. So could anyone tell me if "Critical Natives" is a sort of "public feature" of OpenJDK? And is there much value to complement the implementation for AArch64? For anything to be fixed we'd need to write some code that uses critical natives, at least to test it. It'd be interesting to see what this could be used for. It might be useful. -- Andrew Haley (he/him) Java Platform Lead Engineer Red Hat UK Ltd. https://keybase.io/andrewhaley EAC8 43EB D3EF DB98 CC77 2FAD A5CD 6035 332F A671 From adinn at redhat.com Thu Dec 19 10:31:00 2019 From: adinn at redhat.com (Andrew Dinn) Date: Thu, 19 Dec 2019 10:31:00 +0000 Subject: [aarch64-port-dev ] RFR: 8229351: AArch64: Make the stub threshold of string_compare intrinsic tunable In-Reply-To: References: <43199499-782e-4747-1037-e02dbfc8f1c1@redhat.com> Message-ID: On 19/12/2019 07:51, Patrick Zhang OS wrote: > Appreciate your reviews. > > I updated the list of reviewers accordingly. > http://cr.openjdk.java.net/~qpzhang/8229351/webrev.06/jdk.changeset > > If no further comments, could any committer please help push it? > Thanks. I have pushed this to the jdk repo. 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 From adinn at redhat.com Thu Dec 19 10:32:57 2019 From: adinn at redhat.com (Andrew Dinn) Date: Thu, 19 Dec 2019 10:32:57 +0000 Subject: [aarch64-port-dev ] RFR (trivial): 8234228: AArch64: Clean up redundant temp vars in generate_compare_long_string_different_encoding In-Reply-To: References: <761841e0-995d-ceef-50e0-0d5c72beb77e@redhat.com> Message-ID: <9d40840e-2a92-383e-a5c1-cf9ed44938f6@redhat.com> On 19/12/2019 04:21, Patrick Zhang OS wrote: > Thanks Andrew, I uploaded a new webrev: > http://cr.openjdk.java.net/~qpzhang/8234228/webrev.02. Nothing > changed in code, I rebased it on the latest tip, checked building, > and updated the reviewer list. Could you please help sponsor and push > it? Thanks in advance. This has been pushed. 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 From ci_notify at linaro.org Thu Dec 19 17:08:16 2019 From: ci_notify at linaro.org (ci_notify at linaro.org) Date: Thu, 19 Dec 2019 17:08:16 +0000 (UTC) Subject: [aarch64-port-dev ] JTREG, JCStress, SPECjbb2015 and Hadoop/Terasort results for OpenJDK JDK on AArch64 Message-ID: <1294486432.5887.1576775297553.JavaMail.javamailuser@localhost> This is a summary of the JTREG test results =========================================== The build and test results are cycled every 15 days. For detailed information on the test output please refer to: http://openjdk.linaro.org/jdkX/openjdk-jtreg-nightly-tests/summary/2019/352/summary.html ------------------------------------------------------------------------------- client-release/hotspot ------------------------------------------------------------------------------- Build 0: aarch64/2018/oct/15 pass: 5,780; fail: 19; not run: 90 ------------------------------------------------------------------------------- client-release/jdk ------------------------------------------------------------------------------- Build 0: aarch64/2018/oct/15 pass: 8,495; fail: 670; error: 23 ------------------------------------------------------------------------------- client-release/langtools ------------------------------------------------------------------------------- Build 0: aarch64/2018/oct/15 pass: 3,970; fail: 5 ------------------------------------------------------------------------------- release/hotspot ------------------------------------------------------------------------------- Build 0: aarch64/2019/nov/15 pass: 5,750 Build 1: aarch64/2019/nov/18 pass: 5,750; fail: 1 Build 2: aarch64/2019/nov/20 pass: 5,752 Build 3: aarch64/2019/nov/22 pass: 5,752; fail: 1 Build 4: aarch64/2019/nov/25 pass: 5,752; fail: 1 Build 5: aarch64/2019/nov/27 pass: 5,752; fail: 2 Build 6: aarch64/2019/nov/29 pass: 5,752; fail: 2 Build 7: aarch64/2019/dec/02 pass: 5,753; fail: 4 Build 8: aarch64/2019/dec/04 pass: 5,755; fail: 2 Build 9: aarch64/2019/dec/07 pass: 5,762; fail: 1 Build 10: aarch64/2019/dec/09 pass: 5,762; fail: 1 Build 11: aarch64/2019/dec/11 pass: 5,765; fail: 44 Build 12: aarch64/2019/dec/13 pass: 5,765; fail: 45 Build 13: aarch64/2019/dec/16 pass: 5,764; fail: 45 Build 14: aarch64/2019/dec/18 pass: 5,765; fail: 44 1 fatal errors were detected; please follow the link above for more detail. ------------------------------------------------------------------------------- release/jdk ------------------------------------------------------------------------------- Build 0: aarch64/2019/nov/15 pass: 8,756; fail: 511; error: 19 Build 1: aarch64/2019/nov/18 pass: 8,765; fail: 504; error: 18 Build 2: aarch64/2019/nov/20 pass: 8,768; fail: 504; error: 19 Build 3: aarch64/2019/nov/22 pass: 8,769; fail: 507; error: 18 Build 4: aarch64/2019/nov/25 pass: 8,775; fail: 509; error: 17 Build 5: aarch64/2019/nov/27 pass: 8,779; fail: 506; error: 22 Build 6: aarch64/2019/nov/29 pass: 8,784; fail: 503; error: 20 Build 7: aarch64/2019/dec/02 pass: 8,784; fail: 507; error: 19 Build 8: aarch64/2019/dec/04 pass: 8,788; fail: 505; error: 17 Build 9: aarch64/2019/dec/07 pass: 8,819; fail: 524; error: 17 Build 10: aarch64/2019/dec/09 pass: 8,820; fail: 519; error: 21 Build 11: aarch64/2019/dec/11 pass: 8,818; fail: 520; error: 18 Build 12: aarch64/2019/dec/13 pass: 8,811; fail: 530; error: 17 Build 13: aarch64/2019/dec/16 pass: 8,813; fail: 529; error: 17 Build 14: aarch64/2019/dec/18 pass: 8,827; fail: 520; error: 16 2 fatal errors were detected; please follow the link above for more detail. ------------------------------------------------------------------------------- release/langtools ------------------------------------------------------------------------------- Build 0: aarch64/2019/nov/15 pass: 3,981 Build 1: aarch64/2019/nov/18 pass: 3,981 Build 2: aarch64/2019/nov/20 pass: 3,981 Build 3: aarch64/2019/nov/22 pass: 3,981 Build 4: aarch64/2019/nov/25 pass: 3,983 Build 5: aarch64/2019/nov/27 pass: 4,006 Build 6: aarch64/2019/nov/29 pass: 4,006 Build 7: aarch64/2019/dec/02 pass: 4,002; fail: 5; error: 1 Build 8: aarch64/2019/dec/04 pass: 4,008 Build 9: aarch64/2019/dec/07 pass: 4,019 Build 10: aarch64/2019/dec/09 pass: 4,019 Build 11: aarch64/2019/dec/11 pass: 4,021 Build 12: aarch64/2019/dec/13 pass: 4,029 Build 13: aarch64/2019/dec/16 pass: 4,030 Build 14: aarch64/2019/dec/18 pass: 4,030 ------------------------------------------------------------------------------- server-release/hotspot ------------------------------------------------------------------------------- Build 0: aarch64/2018/oct/15 pass: 5,787; fail: 18; not run: 90 ------------------------------------------------------------------------------- server-release/jdk ------------------------------------------------------------------------------- Build 0: aarch64/2018/oct/15 pass: 8,476; fail: 686; error: 27 ------------------------------------------------------------------------------- server-release/langtools ------------------------------------------------------------------------------- Build 0: aarch64/2018/oct/15 pass: 3,970; fail: 5 Previous results can be found here: http://openjdk.linaro.org/jdkX/openjdk-jtreg-nightly-tests/index.html SPECjbb2015 composite regression test completed =============================================== This test measures the relative performance of the server compiler running the SPECjbb2015 composite tests and compares the performance against the baseline performance of the server compiler taken on 2016-11-21. In accordance with [1], the SPECjbb2015 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): 8.04x Relative performance: Server critical-jOPS (nc): 12.02x Details of the test setup and historical results may be found here: http://openjdk.linaro.org/jdkX/SPECjbb2015-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 server compiler on 2014-04-01. Relative performance: Zero: 1.0, Server: 207.57 Server 207.57 / Server 2014-04-01 (71.00): 2.92x Details of the test setup and historical results may be found here: http://openjdk.linaro.org/jdkX/hadoop-terasort-benchmark-results/ This is a summary of the jcstress test results ============================================== The build and test results are cycled every 15 days. 2019-11-16 pass rate: 10490/10490, results: http://openjdk.linaro.org/jdkX/jcstress-nightly-runs/2019/319/results/ 2019-11-19 pass rate: 10490/10490, results: http://openjdk.linaro.org/jdkX/jcstress-nightly-runs/2019/322/results/ 2019-11-21 pass rate: 10490/10490, results: http://openjdk.linaro.org/jdkX/jcstress-nightly-runs/2019/324/results/ 2019-11-23 pass rate: 10490/10490, results: http://openjdk.linaro.org/jdkX/jcstress-nightly-runs/2019/326/results/ 2019-11-26 pass rate: 10490/10490, results: http://openjdk.linaro.org/jdkX/jcstress-nightly-runs/2019/329/results/ 2019-12-03 pass rate: 10490/10490, results: http://openjdk.linaro.org/jdkX/jcstress-nightly-runs/2019/331/results/ 2019-12-04 pass rate: 10490/10490, results: http://openjdk.linaro.org/jdkX/jcstress-nightly-runs/2019/333/results/ 2019-12-05 pass rate: 10490/10490, results: http://openjdk.linaro.org/jdkX/jcstress-nightly-runs/2019/336/results/ 2019-12-07 pass rate: 10490/10490, results: http://openjdk.linaro.org/jdkX/jcstress-nightly-runs/2019/338/results/ 2019-12-08 pass rate: 10490/10490, results: http://openjdk.linaro.org/jdkX/jcstress-nightly-runs/2019/341/results/ 2019-12-10 pass rate: 10490/10490, results: http://openjdk.linaro.org/jdkX/jcstress-nightly-runs/2019/343/results/ 2019-12-12 pass rate: 10490/10490, results: http://openjdk.linaro.org/jdkX/jcstress-nightly-runs/2019/345/results/ 2019-12-14 pass rate: 10490/10490, results: http://openjdk.linaro.org/jdkX/jcstress-nightly-runs/2019/347/results/ 2019-12-17 pass rate: 10490/10490, results: http://openjdk.linaro.org/jdkX/jcstress-nightly-runs/2019/350/results/ 2019-12-19 pass rate: 10490/10490, results: http://openjdk.linaro.org/jdkX/jcstress-nightly-runs/2019/352/results/ For detailed information on the test output please refer to: http://openjdk.linaro.org/jdkX/jcstress-nightly-runs/ From aph at redhat.com Thu Dec 19 21:38:26 2019 From: aph at redhat.com (Andrew Haley) Date: Thu, 19 Dec 2019 22:38:26 +0100 Subject: [aarch64-port-dev ] Question: JNI critical native support is not fully implemented for AArch64? In-Reply-To: <0d784d57-ad2f-4145-bdfe-8933b2045ce5@oracle.com> References: <19c47e46-c0b3-ef63-879b-b736c210e1ad@redhat.com> <0d784d57-ad2f-4145-bdfe-8933b2045ce5@oracle.com> Message-ID: On 12/19/19 11:37 AM, Robbin Ehn wrote: > I need to test the performance difference, but if it's small I would suggest > removing it completely. > > So before anyone starts implementing/spreading the use of this can we have some > time to evaluate? Sure, what's another couple of years among friends? ;-) -- Andrew Haley (he/him) Java Platform Lead Engineer Red Hat UK Ltd. https://keybase.io/andrewhaley EAC8 43EB D3EF DB98 CC77 2FAD A5CD 6035 332F A671 From ci_notify at linaro.org Thu Dec 19 22:56:23 2019 From: ci_notify at linaro.org (ci_notify at linaro.org) Date: Thu, 19 Dec 2019 22:56:23 +0000 (UTC) Subject: [aarch64-port-dev ] JTREG, JCStress, SPECjbb2015 and Hadoop/Terasort results for OpenJDK 8u on AArch64 Message-ID: <1392290590.5958.1576796183993.JavaMail.javamailuser@localhost> This is a summary of the JTREG test results =========================================== The build and test results are cycled every 15 days. For detailed information on the test output please refer to: http://openjdk.linaro.org/jdk8u/openjdk-jtreg-nightly-tests/summary/2019/353/summary.html ------------------------------------------------------------------------------- release/hotspot ------------------------------------------------------------------------------- Build 0: aarch64/2019/aug/04 pass: 808; fail: 30; error: 2 Build 1: aarch64/2019/aug/06 pass: 799; fail: 29; error: 12 Build 2: aarch64/2019/aug/08 pass: 830; fail: 9; error: 1 Build 3: aarch64/2019/aug/11 pass: 825; fail: 14; error: 1 Build 4: aarch64/2019/aug/13 pass: 830; fail: 9; error: 1 Build 5: aarch64/2019/aug/15 pass: 837; fail: 9; error: 1 Build 6: aarch64/2019/aug/17 pass: 837; fail: 9; error: 1 Build 7: aarch64/2019/aug/22 pass: 837; fail: 9; error: 1 Build 8: aarch64/2019/sep/10 pass: 838; fail: 13; error: 1 Build 9: aarch64/2019/sep/21 pass: 838; fail: 13; error: 1 Build 10: aarch64/2019/nov/02 pass: 843; fail: 9; error: 1 Build 11: aarch64/2019/nov/14 pass: 843; fail: 9; error: 1 Build 12: aarch64/2019/dec/16 pass: 843; fail: 10; error: 1 Build 13: aarch64/2019/dec/17 pass: 846; fail: 10; error: 2 Build 14: aarch64/2019/dec/19 pass: 846; fail: 10; error: 2 ------------------------------------------------------------------------------- release/jdk ------------------------------------------------------------------------------- Build 0: aarch64/2019/aug/04 pass: 5,949; fail: 270; error: 24 Build 1: aarch64/2019/aug/06 pass: 5,945; fail: 275; error: 23 Build 2: aarch64/2019/aug/08 pass: 5,953; fail: 267; error: 23 Build 3: aarch64/2019/aug/11 pass: 5,947; fail: 272; error: 25 Build 4: aarch64/2019/aug/13 pass: 5,962; fail: 258; error: 24 Build 5: aarch64/2019/aug/15 pass: 5,955; fail: 266; error: 23 Build 6: aarch64/2019/aug/17 pass: 5,951; fail: 269; error: 24 Build 7: aarch64/2019/aug/22 pass: 5,945; fail: 279; error: 20 Build 8: aarch64/2019/sep/10 pass: 5,951; fail: 273; error: 23 Build 9: aarch64/2019/sep/21 pass: 5,964; fail: 261; error: 22 Build 10: aarch64/2019/nov/02 pass: 5,956; fail: 278; error: 18 Build 11: aarch64/2019/nov/14 pass: 5,956; fail: 275; error: 21 Build 12: aarch64/2019/dec/16 pass: 5,964; fail: 267; error: 21 Build 13: aarch64/2019/dec/17 pass: 5,963; fail: 267; error: 22 Build 14: aarch64/2019/dec/19 pass: 5,959; fail: 272; error: 21 2 fatal errors were detected; please follow the link above for more detail. ------------------------------------------------------------------------------- release/langtools ------------------------------------------------------------------------------- Build 0: aarch64/2019/aug/04 pass: 3,116; fail: 2 Build 1: aarch64/2019/aug/06 pass: 3,116; fail: 2 Build 2: aarch64/2019/aug/08 pass: 3,116; fail: 2 Build 3: aarch64/2019/aug/11 pass: 3,116; fail: 2 Build 4: aarch64/2019/aug/13 pass: 3,116; fail: 2 Build 5: aarch64/2019/aug/15 pass: 3,116; fail: 2 Build 6: aarch64/2019/aug/17 pass: 3,116; fail: 2 Build 7: aarch64/2019/aug/22 pass: 3,116; fail: 2 Build 8: aarch64/2019/sep/10 pass: 3,116; fail: 2 Build 9: aarch64/2019/sep/21 pass: 3,116; fail: 2 Build 10: aarch64/2019/nov/02 pass: 3,116; fail: 2 Build 11: aarch64/2019/nov/14 pass: 3,116; fail: 2 Build 12: aarch64/2019/dec/16 pass: 3,116; fail: 2 Build 13: aarch64/2019/dec/17 pass: 3,117; fail: 2 Build 14: aarch64/2019/dec/19 pass: 3,117; fail: 2 Previous results can be found here: http://openjdk.linaro.org/jdk8u/openjdk-jtreg-nightly-tests/index.html SPECjbb2015 composite regression test completed =============================================== This test measures the relative performance of the server compiler running the SPECjbb2015 composite tests and compares the performance against the baseline performance of the server compiler taken on 2016-11-21. In accordance with [1], the SPECjbb2015 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): 6.73x Relative performance: Server critical-jOPS (nc): 8.78x Details of the test setup and historical results may be found here: http://openjdk.linaro.org/jdk8u/SPECjbb2015-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 server compiler on 2014-04-01. Relative performance: Zero: 1.0, Server: 176.44 Server 176.44 / Server 2014-04-01 (71.00): 2.49x Details of the test setup and historical results may be found here: http://openjdk.linaro.org/jdk8u/hadoop-terasort-benchmark-results/ This is a summary of the jcstress test results ============================================== The build and test results are cycled every 15 days. 2019-08-05 pass rate: 8229/8229, results: http://openjdk.linaro.org/jdk8u/jcstress-nightly-runs/2019/216/results/ 2019-08-07 pass rate: 8229/8229, results: http://openjdk.linaro.org/jdk8u/jcstress-nightly-runs/2019/218/results/ 2019-08-09 pass rate: 8229/8229, results: http://openjdk.linaro.org/jdk8u/jcstress-nightly-runs/2019/220/results/ 2019-08-12 pass rate: 8230/8230, results: http://openjdk.linaro.org/jdk8u/jcstress-nightly-runs/2019/223/results/ 2019-08-13 pass rate: 8230/8230, results: http://openjdk.linaro.org/jdk8u/jcstress-nightly-runs/2019/225/results/ 2019-08-16 pass rate: 8230/8230, results: http://openjdk.linaro.org/jdk8u/jcstress-nightly-runs/2019/227/results/ 2019-08-17 pass rate: 8230/8230, results: http://openjdk.linaro.org/jdk8u/jcstress-nightly-runs/2019/229/results/ 2019-08-23 pass rate: 8230/8230, results: http://openjdk.linaro.org/jdk8u/jcstress-nightly-runs/2019/234/results/ 2019-09-11 pass rate: 8230/8230, results: http://openjdk.linaro.org/jdk8u/jcstress-nightly-runs/2019/253/results/ 2019-09-22 pass rate: 8230/8230, results: http://openjdk.linaro.org/jdk8u/jcstress-nightly-runs/2019/264/results/ 2019-11-02 pass rate: 8230/8230, results: http://openjdk.linaro.org/jdk8u/jcstress-nightly-runs/2019/306/results/ 2019-11-15 pass rate: 8231/8231, results: http://openjdk.linaro.org/jdk8u/jcstress-nightly-runs/2019/318/results/ 2019-12-16 pass rate: 8231/8231, results: http://openjdk.linaro.org/jdk8u/jcstress-nightly-runs/2019/350/results/ 2019-12-18 pass rate: 8231/8231, results: http://openjdk.linaro.org/jdk8u/jcstress-nightly-runs/2019/351/results/ 2019-12-19 pass rate: 8231/8231, results: http://openjdk.linaro.org/jdk8u/jcstress-nightly-runs/2019/353/results/ For detailed information on the test output please refer to: http://openjdk.linaro.org/jdk8u/jcstress-nightly-runs/ From gnu.andrew at redhat.com Fri Dec 20 07:30:54 2019 From: gnu.andrew at redhat.com (gnu.andrew at redhat.com) Date: Fri, 20 Dec 2019 07:30:54 +0000 Subject: [aarch64-port-dev ] hg: aarch64-port/jdk8u-shenandoah: 7 new changesets Message-ID: <201912200730.xBK7UtZE024841@aojmv0008.oracle.com> Changeset: be3a6b2c7982 Author: andrew Date: 2019-11-18 16:41 +0000 URL: https://hg.openjdk.java.net/aarch64-port/jdk8u-shenandoah/rev/be3a6b2c7982 Added tag jdk8u242-b02 for changeset d20799349800 ! .hgtags Changeset: 3b1e9620d490 Author: andrew Date: 2019-11-28 01:00 +0000 URL: https://hg.openjdk.java.net/aarch64-port/jdk8u-shenandoah/rev/3b1e9620d490 Merge jdk8u242-b02 ! .hgtags Changeset: 1adf8e41a042 Author: andrew Date: 2019-11-28 01:19 +0000 URL: https://hg.openjdk.java.net/aarch64-port/jdk8u-shenandoah/rev/1adf8e41a042 Added tag aarch64-shenandoah-jdk8u242-b02 for changeset 3b1e9620d490 ! .hgtags Changeset: 813d61736302 Author: andrew Date: 2019-11-27 05:33 +0000 URL: https://hg.openjdk.java.net/aarch64-port/jdk8u-shenandoah/rev/813d61736302 Added tag jdk8u242-b03 for changeset be3a6b2c7982 ! .hgtags Changeset: 30768a181ad0 Author: andrew Date: 2019-12-04 16:24 +0000 URL: https://hg.openjdk.java.net/aarch64-port/jdk8u-shenandoah/rev/30768a181ad0 Added tag jdk8u242-b04 for changeset 813d61736302 ! .hgtags Changeset: f0c16433e7c9 Author: andrew Date: 2019-12-04 18:22 +0000 URL: https://hg.openjdk.java.net/aarch64-port/jdk8u-shenandoah/rev/f0c16433e7c9 Merge jdk8u242-b04 ! .hgtags Changeset: 16f824f17d9a Author: andrew Date: 2019-12-04 18:25 +0000 URL: https://hg.openjdk.java.net/aarch64-port/jdk8u-shenandoah/rev/16f824f17d9a Added tag aarch64-shenandoah-jdk8u242-b04 for changeset f0c16433e7c9 ! .hgtags From gnu.andrew at redhat.com Fri Dec 20 07:31:01 2019 From: gnu.andrew at redhat.com (gnu.andrew at redhat.com) Date: Fri, 20 Dec 2019 07:31:01 +0000 Subject: [aarch64-port-dev ] hg: aarch64-port/jdk8u-shenandoah/corba: 7 new changesets Message-ID: <201912200731.xBK7V10t024916@aojmv0008.oracle.com> Changeset: 89f67ddac3c9 Author: andrew Date: 2019-11-18 16:41 +0000 URL: https://hg.openjdk.java.net/aarch64-port/jdk8u-shenandoah/corba/rev/89f67ddac3c9 Added tag jdk8u242-b02 for changeset b3fbd77f16f6 ! .hgtags Changeset: f9db961f5ed0 Author: andrew Date: 2019-11-28 01:00 +0000 URL: https://hg.openjdk.java.net/aarch64-port/jdk8u-shenandoah/corba/rev/f9db961f5ed0 Merge jdk8u242-b02 ! .hgtags Changeset: 5fb7e591203c Author: andrew Date: 2019-11-28 01:19 +0000 URL: https://hg.openjdk.java.net/aarch64-port/jdk8u-shenandoah/corba/rev/5fb7e591203c Added tag aarch64-shenandoah-jdk8u242-b02 for changeset f9db961f5ed0 ! .hgtags Changeset: 1835a96a04a6 Author: andrew Date: 2019-11-27 05:33 +0000 URL: https://hg.openjdk.java.net/aarch64-port/jdk8u-shenandoah/corba/rev/1835a96a04a6 Added tag jdk8u242-b03 for changeset 89f67ddac3c9 ! .hgtags Changeset: 201757e54b48 Author: andrew Date: 2019-12-04 16:24 +0000 URL: https://hg.openjdk.java.net/aarch64-port/jdk8u-shenandoah/corba/rev/201757e54b48 Added tag jdk8u242-b04 for changeset 1835a96a04a6 ! .hgtags Changeset: f9e0b2a84563 Author: andrew Date: 2019-12-04 18:22 +0000 URL: https://hg.openjdk.java.net/aarch64-port/jdk8u-shenandoah/corba/rev/f9e0b2a84563 Merge jdk8u242-b04 ! .hgtags Changeset: b9b2443f3993 Author: andrew Date: 2019-12-04 18:25 +0000 URL: https://hg.openjdk.java.net/aarch64-port/jdk8u-shenandoah/corba/rev/b9b2443f3993 Added tag aarch64-shenandoah-jdk8u242-b04 for changeset f9e0b2a84563 ! .hgtags From gnu.andrew at redhat.com Fri Dec 20 07:31:09 2019 From: gnu.andrew at redhat.com (gnu.andrew at redhat.com) Date: Fri, 20 Dec 2019 07:31:09 +0000 Subject: [aarch64-port-dev ] hg: aarch64-port/jdk8u-shenandoah/jaxp: 7 new changesets Message-ID: <201912200731.xBK7V9o1025149@aojmv0008.oracle.com> Changeset: 616095b698d1 Author: andrew Date: 2019-11-18 16:41 +0000 URL: https://hg.openjdk.java.net/aarch64-port/jdk8u-shenandoah/jaxp/rev/616095b698d1 Added tag jdk8u242-b02 for changeset 91cff4cef209 ! .hgtags Changeset: 0dab7f0a88d7 Author: andrew Date: 2019-11-28 01:00 +0000 URL: https://hg.openjdk.java.net/aarch64-port/jdk8u-shenandoah/jaxp/rev/0dab7f0a88d7 Merge jdk8u242-b02 ! .hgtags Changeset: 8783a983f501 Author: andrew Date: 2019-11-28 01:19 +0000 URL: https://hg.openjdk.java.net/aarch64-port/jdk8u-shenandoah/jaxp/rev/8783a983f501 Added tag aarch64-shenandoah-jdk8u242-b02 for changeset 0dab7f0a88d7 ! .hgtags Changeset: 2199192fb5ec Author: andrew Date: 2019-11-27 05:33 +0000 URL: https://hg.openjdk.java.net/aarch64-port/jdk8u-shenandoah/jaxp/rev/2199192fb5ec Added tag jdk8u242-b03 for changeset 616095b698d1 ! .hgtags Changeset: 41b0b125cb4a Author: andrew Date: 2019-12-04 16:24 +0000 URL: https://hg.openjdk.java.net/aarch64-port/jdk8u-shenandoah/jaxp/rev/41b0b125cb4a Added tag jdk8u242-b04 for changeset 2199192fb5ec ! .hgtags Changeset: a2c2ac8e257e Author: andrew Date: 2019-12-04 18:22 +0000 URL: https://hg.openjdk.java.net/aarch64-port/jdk8u-shenandoah/jaxp/rev/a2c2ac8e257e Merge jdk8u242-b04 ! .hgtags Changeset: f57d5e8e1102 Author: andrew Date: 2019-12-04 18:25 +0000 URL: https://hg.openjdk.java.net/aarch64-port/jdk8u-shenandoah/jaxp/rev/f57d5e8e1102 Added tag aarch64-shenandoah-jdk8u242-b04 for changeset a2c2ac8e257e ! .hgtags From gnu.andrew at redhat.com Fri Dec 20 07:31:16 2019 From: gnu.andrew at redhat.com (gnu.andrew at redhat.com) Date: Fri, 20 Dec 2019 07:31:16 +0000 Subject: [aarch64-port-dev ] hg: aarch64-port/jdk8u-shenandoah/jaxws: 7 new changesets Message-ID: <201912200731.xBK7VG46025232@aojmv0008.oracle.com> Changeset: 6f53efc6747b Author: andrew Date: 2019-11-18 16:42 +0000 URL: https://hg.openjdk.java.net/aarch64-port/jdk8u-shenandoah/jaxws/rev/6f53efc6747b Added tag jdk8u242-b02 for changeset 016be7bdaa27 ! .hgtags Changeset: a9bd1d038ae5 Author: andrew Date: 2019-11-28 01:00 +0000 URL: https://hg.openjdk.java.net/aarch64-port/jdk8u-shenandoah/jaxws/rev/a9bd1d038ae5 Merge jdk8u242-b02 ! .hgtags Changeset: 6db3fdec2aa7 Author: andrew Date: 2019-11-28 01:19 +0000 URL: https://hg.openjdk.java.net/aarch64-port/jdk8u-shenandoah/jaxws/rev/6db3fdec2aa7 Added tag aarch64-shenandoah-jdk8u242-b02 for changeset a9bd1d038ae5 ! .hgtags Changeset: b1722cc8c8d8 Author: andrew Date: 2019-11-27 05:33 +0000 URL: https://hg.openjdk.java.net/aarch64-port/jdk8u-shenandoah/jaxws/rev/b1722cc8c8d8 Added tag jdk8u242-b03 for changeset 6f53efc6747b ! .hgtags Changeset: 5c9d17a5ca58 Author: andrew Date: 2019-12-04 16:24 +0000 URL: https://hg.openjdk.java.net/aarch64-port/jdk8u-shenandoah/jaxws/rev/5c9d17a5ca58 Added tag jdk8u242-b04 for changeset b1722cc8c8d8 ! .hgtags Changeset: 2e43ed855dd3 Author: andrew Date: 2019-12-04 18:22 +0000 URL: https://hg.openjdk.java.net/aarch64-port/jdk8u-shenandoah/jaxws/rev/2e43ed855dd3 Merge jdk8u242-b04 ! .hgtags Changeset: df8a2b7fd76a Author: andrew Date: 2019-12-04 18:25 +0000 URL: https://hg.openjdk.java.net/aarch64-port/jdk8u-shenandoah/jaxws/rev/df8a2b7fd76a Added tag aarch64-shenandoah-jdk8u242-b04 for changeset 2e43ed855dd3 ! .hgtags From gnu.andrew at redhat.com Fri Dec 20 07:31:23 2019 From: gnu.andrew at redhat.com (gnu.andrew at redhat.com) Date: Fri, 20 Dec 2019 07:31:23 +0000 Subject: [aarch64-port-dev ] hg: aarch64-port/jdk8u-shenandoah/langtools: 7 new changesets Message-ID: <201912200731.xBK7VNev025414@aojmv0008.oracle.com> Changeset: fbe99e0b4e74 Author: andrew Date: 2019-11-18 16:42 +0000 URL: https://hg.openjdk.java.net/aarch64-port/jdk8u-shenandoah/langtools/rev/fbe99e0b4e74 Added tag jdk8u242-b02 for changeset 5b0a0cf41fc1 ! .hgtags Changeset: 892104130124 Author: andrew Date: 2019-11-28 01:00 +0000 URL: https://hg.openjdk.java.net/aarch64-port/jdk8u-shenandoah/langtools/rev/892104130124 Merge jdk8u242-b02 ! .hgtags Changeset: 4429888ab93a Author: andrew Date: 2019-11-28 01:19 +0000 URL: https://hg.openjdk.java.net/aarch64-port/jdk8u-shenandoah/langtools/rev/4429888ab93a Added tag aarch64-shenandoah-jdk8u242-b02 for changeset 892104130124 ! .hgtags Changeset: 764b933d3443 Author: andrew Date: 2019-11-27 05:33 +0000 URL: https://hg.openjdk.java.net/aarch64-port/jdk8u-shenandoah/langtools/rev/764b933d3443 Added tag jdk8u242-b03 for changeset fbe99e0b4e74 ! .hgtags Changeset: fefafdbaeb2d Author: andrew Date: 2019-12-04 16:24 +0000 URL: https://hg.openjdk.java.net/aarch64-port/jdk8u-shenandoah/langtools/rev/fefafdbaeb2d Added tag jdk8u242-b04 for changeset 764b933d3443 ! .hgtags Changeset: 7dd963f2c23a Author: andrew Date: 2019-12-04 18:22 +0000 URL: https://hg.openjdk.java.net/aarch64-port/jdk8u-shenandoah/langtools/rev/7dd963f2c23a Merge jdk8u242-b04 ! .hgtags Changeset: 43cc24e9b7d5 Author: andrew Date: 2019-12-04 18:25 +0000 URL: https://hg.openjdk.java.net/aarch64-port/jdk8u-shenandoah/langtools/rev/43cc24e9b7d5 Added tag aarch64-shenandoah-jdk8u242-b04 for changeset 7dd963f2c23a ! .hgtags From gnu.andrew at redhat.com Fri Dec 20 07:31:39 2019 From: gnu.andrew at redhat.com (gnu.andrew at redhat.com) Date: Fri, 20 Dec 2019 07:31:39 +0000 Subject: [aarch64-port-dev ] hg: aarch64-port/jdk8u-shenandoah/jdk: 20 new changesets Message-ID: <201912200731.xBK7VdAg025646@aojmv0008.oracle.com> Changeset: fa2bd03e80bd Author: rhalade Date: 2019-10-09 12:21 -0700 URL: https://hg.openjdk.java.net/aarch64-port/jdk8u-shenandoah/jdk/rev/fa2bd03e80bd 8231887: ComodoCA.java fails because certificate was revoked Reviewed-by: mullan, clanger ! test/security/infra/java/security/cert/CertPathValidator/certification/ComodoCA.java Changeset: 7bae06012fbf Author: redestad Date: 2015-01-16 12:41 +0100 URL: https://hg.openjdk.java.net/aarch64-port/jdk8u-shenandoah/jdk/rev/7bae06012fbf 8068736: Avoid synchronization on Executable/Field.declaredAnnotations Reviewed-by: jfranck, psandoz ! src/share/classes/java/lang/reflect/Executable.java ! src/share/classes/java/lang/reflect/Field.java Changeset: ac2bee64b971 Author: serb Date: 2019-09-12 22:20 -0700 URL: https://hg.openjdk.java.net/aarch64-port/jdk8u-shenandoah/jdk/rev/ac2bee64b971 8225101: Crash at sun.awt.X11.XlibWrapper.XkbGetUpdatedMap when change keybord map Reviewed-by: prr, pbansal ! src/solaris/classes/sun/awt/X11/XToolkit.java Changeset: 9411ed365793 Author: serb Date: 2018-11-09 22:25 -0800 URL: https://hg.openjdk.java.net/aarch64-port/jdk8u-shenandoah/jdk/rev/9411ed365793 8213568: Typo in java/awt/GraphicsEnvironment/LoadLock/GE_init5.java Reviewed-by: prr ! test/java/awt/GraphicsEnvironment/LoadLock/GE_init5.java Changeset: ca22fba77f9d Author: martin Date: 2014-09-05 19:06 -0700 URL: https://hg.openjdk.java.net/aarch64-port/jdk8u-shenandoah/jdk/rev/ca22fba77f9d 8057986: freetype code to get glyph outline does not handle initial control point properly Reviewed-by: prr, dougfelt Contributed-by: Behdad Esfahbod , Igor Kopylov ! src/share/native/sun/font/freetypeScaler.c + test/java/awt/font/GlyphVector/GlyphVectorOutline.java Changeset: 2b292ab0ed9a Author: bpb Date: 2015-02-17 12:02 -0800 URL: https://hg.openjdk.java.net/aarch64-port/jdk8u-shenandoah/jdk/rev/2b292ab0ed9a 8073347: javadoc of Formattable messed up by JDK-8019857 Summary: Change sample code formatting to the currently blessed idiom. Reviewed-by: martin ! src/share/classes/java/util/Formattable.java Changeset: 2f564a16517d Author: andrew Date: 2019-11-18 16:42 +0000 URL: https://hg.openjdk.java.net/aarch64-port/jdk8u-shenandoah/jdk/rev/2f564a16517d Added tag jdk8u242-b02 for changeset 2b292ab0ed9a ! .hgtags Changeset: 41a9126e70e6 Author: andrew Date: 2019-11-28 01:00 +0000 URL: https://hg.openjdk.java.net/aarch64-port/jdk8u-shenandoah/jdk/rev/41a9126e70e6 Merge jdk8u242-b02 ! .hgtags ! src/share/classes/java/lang/reflect/Executable.java ! src/share/classes/java/lang/reflect/Field.java ! src/share/native/sun/font/freetypeScaler.c ! src/solaris/classes/sun/awt/X11/XToolkit.java Changeset: e134538b63b0 Author: andrew Date: 2019-11-28 01:19 +0000 URL: https://hg.openjdk.java.net/aarch64-port/jdk8u-shenandoah/jdk/rev/e134538b63b0 Added tag aarch64-shenandoah-jdk8u242-b02 for changeset 41a9126e70e6 ! .hgtags Changeset: b12b31b17aaa Author: andrew Date: 2019-11-27 05:33 +0000 URL: https://hg.openjdk.java.net/aarch64-port/jdk8u-shenandoah/jdk/rev/b12b31b17aaa Added tag jdk8u242-b03 for changeset 2f564a16517d ! .hgtags Changeset: d7afdf6fa7d6 Author: kaddepalli Date: 2018-12-14 11:00 +0530 URL: https://hg.openjdk.java.net/aarch64-port/jdk8u-shenandoah/jdk/rev/d7afdf6fa7d6 8196681: Java Access Bridge logging and debug flags dynamically controlled Reviewed-by: serb, sveerabhadra, zgu Contributed-by: Alex Kashchenko ! src/windows/classes/com/sun/java/accessibility/AccessBridge.java ! src/windows/native/sun/bridge/AccessBridgeATInstance.cpp ! src/windows/native/sun/bridge/AccessBridgeDebug.cpp ! src/windows/native/sun/bridge/AccessBridgeDebug.h ! src/windows/native/sun/bridge/AccessBridgeEventHandler.cpp ! src/windows/native/sun/bridge/AccessBridgeJavaEntryPoints.cpp ! src/windows/native/sun/bridge/AccessBridgeJavaVMInstance.cpp ! src/windows/native/sun/bridge/AccessBridgeMessageQueue.cpp ! src/windows/native/sun/bridge/JavaAccessBridge.cpp ! src/windows/native/sun/bridge/WinAccessBridge.cpp Changeset: 507cff819ab6 Author: kaddepalli Date: 2019-04-25 15:19 +0530 URL: https://hg.openjdk.java.net/aarch64-port/jdk8u-shenandoah/jdk/rev/507cff819ab6 8219914: Change the environment variable for Java Access Bridge logging to have a directory. Reviewed-by: prr ! src/windows/native/sun/bridge/AccessBridgeDebug.cpp ! src/windows/native/sun/bridge/AccessBridgeDebug.h ! src/windows/native/sun/bridge/JavaAccessBridge.cpp ! src/windows/native/sun/bridge/WinAccessBridge.cpp Changeset: 0744ab2988f4 Author: dmarkov Date: 2019-08-23 14:25 +0100 URL: https://hg.openjdk.java.net/aarch64-port/jdk8u-shenandoah/jdk/rev/0744ab2988f4 8225505: ctrl-F1 does not show the tooltip of a menu item (JMenuItems) Reviewed-by: psadhukhan, serb ! src/share/classes/javax/swing/ToolTipManager.java + test/javax/swing/ToolTipManager/JMenuItemToolTipKeyBindingsTest/JMenuItemToolTipKeyBindingsTest.java Changeset: eb5f5070c60b Author: serb Date: 2019-08-27 04:43 -0700 URL: https://hg.openjdk.java.net/aarch64-port/jdk8u-shenandoah/jdk/rev/eb5f5070c60b 8146238: [macosx] Java2D Queue Flusher crash on OSX after switching between user accounts Reviewed-by: prr, avu ! src/macosx/classes/sun/java2d/opengl/CGLSurfaceData.java ! src/macosx/native/sun/java2d/opengl/CGLSurfaceData.m ! src/share/classes/sun/java2d/opengl/OGLSurfaceData.java ! src/share/native/sun/java2d/opengl/OGLSurfaceData.c ! src/share/native/sun/java2d/opengl/OGLSurfaceData.h ! src/solaris/classes/sun/java2d/opengl/GLXSurfaceData.java ! src/solaris/native/sun/java2d/opengl/GLXSurfaceData.c ! src/windows/classes/sun/java2d/opengl/WGLSurfaceData.java ! src/windows/native/sun/java2d/opengl/WGLSurfaceData.c Changeset: 168c73fb6713 Author: ascarpino Date: 2015-06-17 17:41 -0700 URL: https://hg.openjdk.java.net/aarch64-port/jdk8u-shenandoah/jdk/rev/168c73fb6713 8073108: Use x86 and SPARC CPU instructions for GHASH acceleration Reviewed-by: kvn, jrose, phh ! src/share/classes/com/sun/crypto/provider/GHASH.java ! test/com/sun/crypto/provider/Cipher/AES/TestGHASH.java Changeset: 9bdb67104867 Author: bae Date: 2018-11-30 23:21 +0300 URL: https://hg.openjdk.java.net/aarch64-port/jdk8u-shenandoah/jdk/rev/9bdb67104867 8139178: Wrong fontMetrics when printing in Landscape (OpenJDK) Reviewed-by: prr Contributed-by: alvdavi at amazon.com ! src/share/native/sun/font/freetypeScaler.c + test/java/awt/font/Rotate/RotatedFontMetricsTest.java + test/jdk/java/awt/font/Rotate/RotatedFontMetricsTest.java Changeset: 8163e59959ed Author: andrew Date: 2019-12-04 16:23 +0000 URL: https://hg.openjdk.java.net/aarch64-port/jdk8u-shenandoah/jdk/rev/8163e59959ed Merge Changeset: 78d2004f65eb Author: andrew Date: 2019-12-04 16:24 +0000 URL: https://hg.openjdk.java.net/aarch64-port/jdk8u-shenandoah/jdk/rev/78d2004f65eb Added tag jdk8u242-b04 for changeset 8163e59959ed ! .hgtags Changeset: f46862d7faf6 Author: andrew Date: 2019-12-04 18:22 +0000 URL: https://hg.openjdk.java.net/aarch64-port/jdk8u-shenandoah/jdk/rev/f46862d7faf6 Merge jdk8u242-b04 ! .hgtags ! src/share/classes/javax/swing/ToolTipManager.java ! src/share/native/sun/font/freetypeScaler.c Changeset: ca866c6ef6ad Author: andrew Date: 2019-12-04 18:25 +0000 URL: https://hg.openjdk.java.net/aarch64-port/jdk8u-shenandoah/jdk/rev/ca866c6ef6ad Added tag aarch64-shenandoah-jdk8u242-b04 for changeset f46862d7faf6 ! .hgtags From gnu.andrew at redhat.com Fri Dec 20 07:31:48 2019 From: gnu.andrew at redhat.com (gnu.andrew at redhat.com) Date: Fri, 20 Dec 2019 07:31:48 +0000 Subject: [aarch64-port-dev ] hg: aarch64-port/jdk8u-shenandoah/nashorn: 10 new changesets Message-ID: <201912200731.xBK7VmXI025717@aojmv0008.oracle.com> Changeset: 2c0573615bbb Author: andrew Date: 2019-11-18 16:42 +0000 URL: https://hg.openjdk.java.net/aarch64-port/jdk8u-shenandoah/nashorn/rev/2c0573615bbb Added tag jdk8u242-b02 for changeset 49b31f261653 ! .hgtags Changeset: 01a0653768cc Author: andrew Date: 2019-11-28 01:00 +0000 URL: https://hg.openjdk.java.net/aarch64-port/jdk8u-shenandoah/nashorn/rev/01a0653768cc Merge jdk8u242-b02 ! .hgtags Changeset: 576b5a33dc90 Author: andrew Date: 2019-11-28 01:19 +0000 URL: https://hg.openjdk.java.net/aarch64-port/jdk8u-shenandoah/nashorn/rev/576b5a33dc90 Added tag aarch64-shenandoah-jdk8u242-b02 for changeset 01a0653768cc ! .hgtags Changeset: 61edd0c12ca0 Author: andrew Date: 2019-11-27 05:33 +0000 URL: https://hg.openjdk.java.net/aarch64-port/jdk8u-shenandoah/nashorn/rev/61edd0c12ca0 Added tag jdk8u242-b03 for changeset 2c0573615bbb ! .hgtags Changeset: 51635f054bcb Author: hannesw Date: 2018-06-08 11:11 +0200 URL: https://hg.openjdk.java.net/aarch64-port/jdk8u-shenandoah/nashorn/rev/51635f054bcb 8204290: Add check to limit number of capture groups Reviewed-by: sundar, jlaskey ! src/jdk/nashorn/internal/runtime/regexp/joni/Config.java ! src/jdk/nashorn/internal/runtime/regexp/joni/ScanEnvironment.java ! src/jdk/nashorn/internal/runtime/regexp/joni/exception/ErrorMessages.java + test/script/basic/JDK-8204290.js Changeset: 319c1b31d551 Author: hannesw Date: 2018-06-08 11:08 +0200 URL: https://hg.openjdk.java.net/aarch64-port/jdk8u-shenandoah/nashorn/rev/319c1b31d551 8204288: Matching the end of a string followed by an empty greedy regex and a word boundary fails Reviewed-by: sundar, jlaskey ! src/jdk/nashorn/internal/runtime/regexp/joni/ByteCodeMachine.java + test/script/basic/JDK-8204288.js Changeset: 637547562431 Author: andrew Date: 2019-12-04 16:23 +0000 URL: https://hg.openjdk.java.net/aarch64-port/jdk8u-shenandoah/nashorn/rev/637547562431 Merge Changeset: 191f7b51899b Author: andrew Date: 2019-12-04 16:24 +0000 URL: https://hg.openjdk.java.net/aarch64-port/jdk8u-shenandoah/nashorn/rev/191f7b51899b Added tag jdk8u242-b04 for changeset 637547562431 ! .hgtags Changeset: 1d5b860c0200 Author: andrew Date: 2019-12-04 18:22 +0000 URL: https://hg.openjdk.java.net/aarch64-port/jdk8u-shenandoah/nashorn/rev/1d5b860c0200 Merge jdk8u242-b04 ! .hgtags Changeset: 08861135955e Author: andrew Date: 2019-12-04 18:25 +0000 URL: https://hg.openjdk.java.net/aarch64-port/jdk8u-shenandoah/nashorn/rev/08861135955e Added tag aarch64-shenandoah-jdk8u242-b04 for changeset 1d5b860c0200 ! .hgtags From gnu.andrew at redhat.com Fri Dec 20 07:31:40 2019 From: gnu.andrew at redhat.com (Andrew John Hughes) Date: Fri, 20 Dec 2019 07:31:40 +0000 Subject: [aarch64-port-dev ] [RFR] [8u] 8u242-b02 & 8u242-b04 Upstream Sync In-Reply-To: <59729053-f4c1-c2de-a133-31b5f4bf5129@redhat.com> References: <16cb5a5b-3106-0375-14dc-60f25619fe02@redhat.com> <59729053-f4c1-c2de-a133-31b5f4bf5129@redhat.com> Message-ID: On 18/12/2019 14:23, Roman Kennke wrote: > Hi Andrew, > >> Webrevs: https://cr.openjdk.java.net/~andrew/shenandoah-8/u242-b04/ >> >> This includes both the b02 and b04 merges. I'm not aware of an easy way >> to split them using webrev. Merge changesets for each are below. >> >> b03 was empty, so can be ignored. >> >> Merge changesets for b02: >> >> http://cr.openjdk.java.net/~andrew/shenandoah-8/u242-b04/corba/merge-b02.changeset >> http://cr.openjdk.java.net/~andrew/shenandoah-8/u242-b04/jaxp/merge-b02.changeset >> http://cr.openjdk.java.net/~andrew/shenandoah-8/u242-b04/jaxws/merge-b02.changeset >> http://cr.openjdk.java.net/~andrew/shenandoah-8/u242-b04/jdk/merge-b02.changeset >> http://cr.openjdk.java.net/~andrew/shenandoah-8/u242-b04/hotspot/merge-b02.changeset >> http://cr.openjdk.java.net/~andrew/shenandoah-8/u242-b04/langtools/merge-b02.changeset >> http://cr.openjdk.java.net/~andrew/shenandoah-8/u242-b04/nashorn/merge-b02.changeset >> http://cr.openjdk.java.net/~andrew/shenandoah-8/u242-b04/root/merge-b02.changeset >> >> Merge changesets for b04: >> >> http://cr.openjdk.java.net/~andrew/shenandoah-8/u242-b04/corba/merge-b04.changeset >> http://cr.openjdk.java.net/~andrew/shenandoah-8/u242-b04/jaxp/merge-b04.changeset >> http://cr.openjdk.java.net/~andrew/shenandoah-8/u242-b04/jaxws/merge-b04.changeset >> http://cr.openjdk.java.net/~andrew/shenandoah-8/u242-b04/jdk/merge-b04.changeset >> http://cr.openjdk.java.net/~andrew/shenandoah-8/u242-b04/hotspot/merge-b04.changeset >> http://cr.openjdk.java.net/~andrew/shenandoah-8/u242-b04/langtools/merge-b04.changeset >> http://cr.openjdk.java.net/~andrew/shenandoah-8/u242-b04/nashorn/merge-b04.changeset >> http://cr.openjdk.java.net/~andrew/shenandoah-8/u242-b04/root/merge-b04.changeset >> >> Changes in aarch64-shenandoah-jdk8u242-b02: >> - S8057986: freetype code to get glyph outline does not handle initial >> control point properly >> - S8068736: Avoid synchronization on Executable/Field.declaredAnnotations >> - S8073347: javadoc of Formattable messed up by JDK-8019857 >> - S8206173: MallocSiteTable::initialize() doesn't take function >> descriptors into account >> - S8213568: Typo in java/awt/GraphicsEnvironment/LoadLock/GE_init5.java >> - S8218558: NMT stack traces in output should show mt component for >> virtual memory allocations >> - S8225101: Crash at sun.awt.X11.XlibWrapper.XkbGetUpdatedMap when >> change keybord map >> - S8228888: C2 compilation fails with assert "m has strange control" >> - S8229020: Failure on CPUs allowing loads reordering: >> assert(_tasks[t] == 1) failed: What else? >> - S8229169: False failure of GenericTaskQueue::pop_local on >> architectures with weak memory model >> - S8230363: C2: Let ConnectionGraph::not_global_escape(Node* n) return >> false if n is not in the CG >> - S8231887: ComodoCA.java fails because certificate was revoked >> - S8233839: aarch64: missing memory barrier in NewObjectArrayStub and >> NewTypeArrayStub >> >> Changes in aarch64-shenandoah-jdk8u242-b04: >> - S8048556: Unnecessary GCLocker-initiated young GCs >> - S8073108: Use x86 and SPARC CPU instructions for GHASH acceleration >> - S8130341: GHASH 32bit intrinsics has AEADBadTagException >> - S8139178: Wrong fontMetrics when printing in Landscape (OpenJDK) >> - S8146238: [macosx] Java2D Queue Flusher crash on OSX after switching >> between user accounts >> - S8196681: Java Access Bridge logging and debug flags dynamically >> controlled >> - S8204288: Matching the end of a string followed by an empty greedy >> regex and a word boundary fails >> - S8204290: Add check to limit number of capture groups >> - S8219914: Change the environment variable for Java Access Bridge >> logging to have a directory. >> - S8225505: ctrl-F1 does not show the tooltip of a menu item (JMenuItems) >> >> Main issues of note: >> - 8233839 is already upstream: >> https://hg.openjdk.java.net/aarch64-port/jdk8u-shenandoah/hotspot/rev/09d4b646f756 >> - There is an AArch64 part of JDK-8073108 which had to be omitted >> upstream. Martin Balao will post this for inclusion here once this is >> pushed. >> >> diffstats for b02: >> >> diffstat for root (b02) >> b/.hgtags | 1 + >> 1 file changed, 1 insertion(+) >> >> diffstat for corba (b02) >> b/.hgtags | 1 + >> 1 file changed, 1 insertion(+) >> >> diffstat for jaxp (b02) >> b/.hgtags | 1 + >> 1 file changed, 1 insertion(+) >> >> diffstat for jaxws (b02) >> b/.hgtags | 1 + >> 1 file changed, 1 insertion(+) >> >> diffstat for langtools (b02) >> b/.hgtags | 1 + >> 1 file changed, 1 insertion(+) >> >> diffstat for nashorn (b02) >> b/.hgtags | 1 + >> 1 file changed, 1 insertion(+) >> >> diffstat for jdk (b02) >> b/.hgtags >> | 1 >> b/src/share/classes/java/lang/reflect/Executable.java >> | 35 >> b/src/share/classes/java/lang/reflect/Field.java >> | 33 >> b/src/share/classes/java/util/Formattable.java >> | 10 >> b/src/share/native/sun/font/freetypeScaler.c >> | 130 +- >> b/src/solaris/classes/sun/awt/X11/XToolkit.java >> | 18 >> b/test/java/awt/GraphicsEnvironment/LoadLock/GE_init5.java >> | 4 >> b/test/java/awt/font/GlyphVector/GlyphVectorOutline.java >> | 91 + >> b/test/security/infra/java/security/cert/CertPathValidator/certification/ComodoCA.java | 504 +++++----- >> 9 files changed, 488 insertions(+), 338 deletions(-) >> >> diffstat for hotspot (b02) >> b/.hgtags | 1 >> b/src/share/vm/opto/escape.cpp | 3 + >> b/src/share/vm/opto/loopopts.cpp | 2 >> b/src/share/vm/services/allocationSite.hpp | 5 +- >> b/src/share/vm/services/mallocSiteTable.cpp | 16 +++++-- >> b/src/share/vm/services/mallocSiteTable.hpp | 8 --- >> b/src/share/vm/services/memBaseline.cpp | 6 +- >> b/src/share/vm/services/memReporter.cpp | 29 ++++++++----- >> b/src/share/vm/services/memReporter.hpp | 2 >> b/src/share/vm/services/virtualMemoryTracker.hpp | 4 - >> b/src/share/vm/utilities/macros.hpp | 8 +++ >> b/src/share/vm/utilities/taskqueue.hpp | 5 ++ >> b/src/share/vm/utilities/workgroup.cpp | 1 >> b/test/compiler/loopopts/StrangeControl.jasm | 48 >> ++++++++++++++++++++++ >> b/test/compiler/loopopts/TestStrangeControl.java | 49 >> +++++++++++++++++++++++ >> 15 files changed, 157 insertions(+), 30 deletions(-) >> >> diffstats for b04: >> >> diffstat for root (b04) >> b/.hgtags | 2 ++ >> 1 file changed, 2 insertions(+) >> >> diffstat for corba (b04) >> b/.hgtags | 2 ++ >> 1 file changed, 2 insertions(+) >> >> diffstat for jaxp (b04) >> b/.hgtags | 2 ++ >> 1 file changed, 2 insertions(+) >> >> diffstat for jaxws (b04) >> b/.hgtags | 2 ++ >> 1 file changed, 2 insertions(+) >> >> diffstat for langtools (b04) >> b/.hgtags | 2 ++ >> 1 file changed, 2 insertions(+) >> >> diffstat for nashorn (b04) >> b/.hgtags >> | 2 >> b/src/jdk/nashorn/internal/runtime/regexp/joni/ByteCodeMachine.java >> | 2 >> b/src/jdk/nashorn/internal/runtime/regexp/joni/Config.java >> | 1 >> b/src/jdk/nashorn/internal/runtime/regexp/joni/ScanEnvironment.java >> | 3 >> b/src/jdk/nashorn/internal/runtime/regexp/joni/exception/ErrorMessages.java | 1 >> b/test/script/basic/JDK-8204288.js >> | 35 ++++++++ >> b/test/script/basic/JDK-8204290.js >> | 40 ++++++++++ >> 7 files changed, 82 insertions(+), 2 deletions(-) >> >> diffstat for jdk (b04) >> b/.hgtags >> | 2 >> b/src/macosx/classes/sun/java2d/opengl/CGLSurfaceData.java >> | 11 >> b/src/macosx/native/sun/java2d/opengl/CGLSurfaceData.m >> | 41 >> b/src/share/classes/com/sun/crypto/provider/GHASH.java >> | 103 - >> b/src/share/classes/javax/swing/ToolTipManager.java >> | 49 >> b/src/share/classes/sun/java2d/opengl/OGLSurfaceData.java >> | 9 >> b/src/share/native/sun/font/freetypeScaler.c >> | 18 >> b/src/share/native/sun/java2d/opengl/OGLSurfaceData.c >> | 12 >> b/src/share/native/sun/java2d/opengl/OGLSurfaceData.h >> | 6 >> b/src/solaris/classes/sun/java2d/opengl/GLXSurfaceData.java >> | 5 >> b/src/solaris/native/sun/java2d/opengl/GLXSurfaceData.c >> | 54 >> b/src/windows/classes/com/sun/java/accessibility/AccessBridge.java >> | 405 ++-- >> b/src/windows/classes/sun/java2d/opengl/WGLSurfaceData.java >> | 6 >> b/src/windows/native/sun/bridge/AccessBridgeATInstance.cpp >> | 26 >> b/src/windows/native/sun/bridge/AccessBridgeDebug.cpp >> | 93 - >> b/src/windows/native/sun/bridge/AccessBridgeDebug.h >> | 4 >> b/src/windows/native/sun/bridge/AccessBridgeEventHandler.cpp >> | 36 >> b/src/windows/native/sun/bridge/AccessBridgeJavaEntryPoints.cpp >> | 896 ++++------ >> b/src/windows/native/sun/bridge/AccessBridgeJavaVMInstance.cpp >> | 10 >> b/src/windows/native/sun/bridge/AccessBridgeMessageQueue.cpp >> | 20 >> b/src/windows/native/sun/bridge/JavaAccessBridge.cpp >> | 743 ++++---- >> b/src/windows/native/sun/bridge/WinAccessBridge.cpp >> | 542 +++--- >> b/src/windows/native/sun/java2d/opengl/WGLSurfaceData.c >> | 52 >> b/test/com/sun/crypto/provider/Cipher/AES/TestGHASH.java >> | 92 - >> b/test/java/awt/font/Rotate/RotatedFontMetricsTest.java >> | 79 >> b/test/javax/swing/ToolTipManager/JMenuItemToolTipKeyBindingsTest/JMenuItemToolTipKeyBindingsTest.java | 144 + >> 26 files changed, 1919 insertions(+), 1539 deletions(-) >> >> diffstat for hotspot (b04) >> b/.hgtags >> | 2 >> b/src/cpu/ppc/vm/vm_version_ppc.cpp >> | 5 >> b/src/cpu/sparc/vm/assembler_sparc.hpp >> | 8 >> b/src/cpu/sparc/vm/stubGenerator_sparc.cpp >> | 128 ++++ >> b/src/cpu/sparc/vm/vm_version_sparc.cpp >> | 11 >> b/src/cpu/x86/vm/assembler_x86.cpp >> | 9 >> b/src/cpu/x86/vm/assembler_x86.hpp >> | 2 >> b/src/cpu/x86/vm/stubGenerator_x86_32.cpp >> | 170 +++++ >> b/src/cpu/x86/vm/stubGenerator_x86_64.cpp >> | 176 ++++++ >> b/src/cpu/x86/vm/stubRoutines_x86.cpp >> | 4 >> b/src/cpu/x86/vm/stubRoutines_x86.hpp >> | 7 >> b/src/cpu/x86/vm/vm_version_x86.cpp >> | 11 >> b/src/share/vm/classfile/vmSymbols.hpp >> | 6 >> b/src/share/vm/gc_implementation/g1/g1CollectedHeap.cpp >> | 6 >> b/src/share/vm/gc_implementation/parallelScavenge/parallelScavengeHeap.cpp | 4 >> b/src/share/vm/gc_implementation/parallelScavenge/vmPSOperations.cpp >> | 10 >> b/src/share/vm/gc_implementation/shared/vmGCOperations.cpp >> | 13 >> b/src/share/vm/gc_implementation/shared/vmGCOperations.hpp >> | 4 >> b/src/share/vm/memory/gcLocker.cpp >> | 14 >> b/src/share/vm/memory/gcLocker.hpp >> | 8 >> b/src/share/vm/memory/genCollectedHeap.cpp >> | 24 >> b/src/share/vm/opto/escape.cpp >> | 1 >> b/src/share/vm/opto/library_call.cpp >> | 37 + >> b/src/share/vm/opto/runtime.cpp >> | 18 >> b/src/share/vm/opto/runtime.hpp >> | 2 >> b/src/share/vm/runtime/globals.hpp >> | 3 >> b/src/share/vm/runtime/stubRoutines.cpp >> | 1 >> b/src/share/vm/runtime/stubRoutines.hpp >> | 2 >> b/src/share/vm/runtime/vmStructs.cpp >> | 1 >> b/test/compiler/7184394/TestAESBase.java >> | 45 + >> b/test/compiler/7184394/TestAESDecode.java >> | 6 >> b/test/compiler/7184394/TestAESEncode.java >> | 8 >> b/test/compiler/7184394/TestAESMain.java >> | 7 >> b/test/gc/stress/gclocker/TestExcessGCLockerCollections.java >> | 285 ++++++++++ >> 34 files changed, 1006 insertions(+), 32 deletions(-) >> >> Both merges were successfully built on x86, x86_64, s390, s390x, ppc, >> ppc64, ppc64le & aarch64. >> >> Ok to push? > > Looks good! Thanks! > Roman > > Thanks! Pushed. -- Andrew :) Senior Free Java Software Engineer Red Hat, Inc. (http://www.redhat.com) PGP Key: ed25519/0xCFDA0F9B35964222 (hkp://keys.gnupg.net) Fingerprint = 5132 579D D154 0ED2 3E04 C5A0 CFDA 0F9B 3596 4222 https://keybase.io/gnu_andrew From gnu.andrew at redhat.com Fri Dec 20 09:34:04 2019 From: gnu.andrew at redhat.com (gnu.andrew at redhat.com) Date: Fri, 20 Dec 2019 09:34:04 +0000 Subject: [aarch64-port-dev ] hg: aarch64-port/jdk8u-shenandoah/hotspot: 20 new changesets Message-ID: <201912200934.xBK9Y47g000331@aojmv0008.oracle.com> Changeset: 02e8f02480b4 Author: andrew Date: 2019-11-27 05:21 +0000 URL: https://hg.openjdk.java.net/aarch64-port/jdk8u-shenandoah/hotspot/rev/02e8f02480b4 Merge Changeset: bf6ea7319424 Author: zgu Date: 2019-02-07 14:29 -0500 URL: https://hg.openjdk.java.net/aarch64-port/jdk8u-shenandoah/hotspot/rev/bf6ea7319424 8218558: NMT stack traces in output should show mt component for virtual memory allocations Reviewed-by: shade, stuefe, coleenp ! src/share/vm/services/allocationSite.hpp ! src/share/vm/services/mallocSiteTable.cpp ! src/share/vm/services/mallocSiteTable.hpp ! src/share/vm/services/memBaseline.cpp ! src/share/vm/services/memReporter.cpp ! src/share/vm/services/memReporter.hpp ! src/share/vm/services/virtualMemoryTracker.hpp Changeset: ac3466ed5cb5 Author: andrew Date: 2019-11-11 17:23 +0000 URL: https://hg.openjdk.java.net/aarch64-port/jdk8u-shenandoah/hotspot/rev/ac3466ed5cb5 Merge Changeset: 9148fcba5de9 Author: simonis Date: 2019-11-07 17:56 -0500 URL: https://hg.openjdk.java.net/aarch64-port/jdk8u-shenandoah/hotspot/rev/9148fcba5de9 8206173: MallocSiteTable::initialize() doesn't take function descriptors into account Reviewed-by: stuefe, zgu ! src/share/vm/services/mallocSiteTable.cpp ! src/share/vm/utilities/macros.hpp Changeset: 1bbf10267ee0 Author: rrich Date: 2019-08-30 09:24 +0200 URL: https://hg.openjdk.java.net/aarch64-port/jdk8u-shenandoah/hotspot/rev/1bbf10267ee0 8230363: C2: Let ConnectionGraph::not_global_escape(Node* n) return false if n is not in the CG Reviewed-by: thartmann, mdoerr ! src/share/vm/opto/escape.cpp Changeset: c2fa0ac49d01 Author: thartmann Date: 2019-08-20 07:47 +0200 URL: https://hg.openjdk.java.net/aarch64-port/jdk8u-shenandoah/hotspot/rev/c2fa0ac49d01 8228888: C2 compilation fails with assert "m has strange control" Summary: Weakened too strong assert. Reviewed-by: kvn, roland ! src/share/vm/opto/loopopts.cpp + test/compiler/loopopts/StrangeControl.jasm + test/compiler/loopopts/TestStrangeControl.java Changeset: 14b0d7d60628 Author: jiefu Date: 2019-08-03 09:04 +0800 URL: https://hg.openjdk.java.net/aarch64-port/jdk8u-shenandoah/hotspot/rev/14b0d7d60628 8229020: Failure on CPUs allowing loads reordering: assert(_tasks[t] == 1) failed: What else? Reviewed-by: tschatzl, kbarrett ! src/share/vm/utilities/workgroup.cpp Changeset: 775e2bf92114 Author: jiefu Date: 2019-08-07 17:00 +0800 URL: https://hg.openjdk.java.net/aarch64-port/jdk8u-shenandoah/hotspot/rev/775e2bf92114 8229169: False failure of GenericTaskQueue::pop_local on architectures with weak memory model Reviewed-by: mdoerr, kbarrett, tschatzl ! src/share/vm/utilities/taskqueue.hpp Changeset: ee19c358e3b8 Author: andrew Date: 2019-11-18 16:42 +0000 URL: https://hg.openjdk.java.net/aarch64-port/jdk8u-shenandoah/hotspot/rev/ee19c358e3b8 Added tag jdk8u242-b02 for changeset 775e2bf92114 ! .hgtags Changeset: e97d1987c8d9 Author: andrew Date: 2019-11-28 01:00 +0000 URL: https://hg.openjdk.java.net/aarch64-port/jdk8u-shenandoah/hotspot/rev/e97d1987c8d9 Merge jdk8u242-b02 ! .hgtags ! src/share/vm/opto/escape.cpp ! src/share/vm/opto/loopopts.cpp ! src/share/vm/utilities/macros.hpp ! src/share/vm/utilities/taskqueue.hpp Changeset: 938f04bb5887 Author: andrew Date: 2019-11-28 01:19 +0000 URL: https://hg.openjdk.java.net/aarch64-port/jdk8u-shenandoah/hotspot/rev/938f04bb5887 Added tag aarch64-shenandoah-jdk8u242-b02 for changeset e97d1987c8d9 ! .hgtags Changeset: ff1018e27c6e Author: andrew Date: 2019-11-27 05:33 +0000 URL: https://hg.openjdk.java.net/aarch64-port/jdk8u-shenandoah/hotspot/rev/ff1018e27c6e Added tag jdk8u242-b03 for changeset ee19c358e3b8 ! .hgtags Changeset: 9f28a4cac6d9 Author: kbarrett Date: 2019-07-31 14:28 -0400 URL: https://hg.openjdk.java.net/aarch64-port/jdk8u-shenandoah/hotspot/rev/9f28a4cac6d9 8048556: Unnecessary GCLocker-initiated young GCs Summary: Fixed recognition of unnecessary GCLocker collections. Reviewed-by: pliden, tschatzl Contributed-by: johnc at azul.com ! src/share/vm/gc_implementation/g1/g1CollectedHeap.cpp ! src/share/vm/gc_implementation/parallelScavenge/parallelScavengeHeap.cpp ! src/share/vm/gc_implementation/parallelScavenge/vmPSOperations.cpp ! src/share/vm/gc_implementation/shared/vmGCOperations.cpp ! src/share/vm/gc_implementation/shared/vmGCOperations.hpp ! src/share/vm/memory/gcLocker.cpp ! src/share/vm/memory/gcLocker.hpp ! src/share/vm/memory/genCollectedHeap.cpp + test/gc/stress/gclocker/TestExcessGCLockerCollections.java Changeset: 44ef77ad417c Author: ascarpino Date: 2015-06-17 17:48 -0700 URL: https://hg.openjdk.java.net/aarch64-port/jdk8u-shenandoah/hotspot/rev/44ef77ad417c 8073108: Use x86 and SPARC CPU instructions for GHASH acceleration Reviewed-by: kvn, jrose, phh ! src/cpu/ppc/vm/vm_version_ppc.cpp ! src/cpu/sparc/vm/assembler_sparc.hpp ! src/cpu/sparc/vm/stubGenerator_sparc.cpp ! src/cpu/sparc/vm/vm_version_sparc.cpp ! src/cpu/x86/vm/assembler_x86.cpp ! src/cpu/x86/vm/assembler_x86.hpp ! src/cpu/x86/vm/stubGenerator_x86_32.cpp ! src/cpu/x86/vm/stubGenerator_x86_64.cpp ! src/cpu/x86/vm/stubRoutines_x86.cpp ! src/cpu/x86/vm/stubRoutines_x86.hpp ! src/cpu/x86/vm/vm_version_x86.cpp ! src/share/vm/classfile/vmSymbols.hpp ! src/share/vm/opto/escape.cpp ! src/share/vm/opto/library_call.cpp ! src/share/vm/opto/runtime.cpp ! src/share/vm/opto/runtime.hpp ! src/share/vm/runtime/globals.hpp ! src/share/vm/runtime/stubRoutines.cpp ! src/share/vm/runtime/stubRoutines.hpp ! src/share/vm/runtime/vmStructs.cpp ! test/compiler/7184394/TestAESBase.java ! test/compiler/7184394/TestAESEncode.java ! test/compiler/7184394/TestAESMain.java Changeset: e55d4d896e30 Author: ascarpino Date: 2015-07-10 11:31 -0700 URL: https://hg.openjdk.java.net/aarch64-port/jdk8u-shenandoah/hotspot/rev/e55d4d896e30 8130341: GHASH 32bit intrinsics has AEADBadTagException Reviewed-by: kvn, mcberg Contributed-by: ygaevsky at azul.com ! src/cpu/x86/vm/stubGenerator_x86_32.cpp ! test/compiler/7184394/TestAESBase.java ! test/compiler/7184394/TestAESDecode.java ! test/compiler/7184394/TestAESEncode.java Changeset: 20258ba5a788 Author: andrew Date: 2019-12-04 16:23 +0000 URL: https://hg.openjdk.java.net/aarch64-port/jdk8u-shenandoah/hotspot/rev/20258ba5a788 Merge Changeset: 371da86379cf Author: andrew Date: 2019-12-04 16:24 +0000 URL: https://hg.openjdk.java.net/aarch64-port/jdk8u-shenandoah/hotspot/rev/371da86379cf Added tag jdk8u242-b04 for changeset 20258ba5a788 ! .hgtags Changeset: 7cb8932d8a4f Author: andrew Date: 2019-12-04 18:22 +0000 URL: https://hg.openjdk.java.net/aarch64-port/jdk8u-shenandoah/hotspot/rev/7cb8932d8a4f Merge jdk8u242-b04 ! .hgtags ! src/cpu/x86/vm/assembler_x86.cpp ! src/cpu/x86/vm/assembler_x86.hpp ! src/cpu/x86/vm/stubGenerator_x86_64.cpp ! src/share/vm/classfile/vmSymbols.hpp ! src/share/vm/gc_implementation/g1/g1CollectedHeap.cpp ! src/share/vm/gc_implementation/parallelScavenge/parallelScavengeHeap.cpp ! src/share/vm/gc_implementation/shared/vmGCOperations.cpp ! src/share/vm/gc_implementation/shared/vmGCOperations.hpp ! src/share/vm/memory/genCollectedHeap.cpp ! src/share/vm/opto/escape.cpp ! src/share/vm/opto/library_call.cpp ! src/share/vm/opto/runtime.cpp ! src/share/vm/opto/runtime.hpp ! src/share/vm/runtime/globals.hpp ! src/share/vm/runtime/stubRoutines.cpp ! src/share/vm/runtime/stubRoutines.hpp ! src/share/vm/runtime/vmStructs.cpp Changeset: 1ce649acf443 Author: andrew Date: 2019-12-04 18:25 +0000 URL: https://hg.openjdk.java.net/aarch64-port/jdk8u-shenandoah/hotspot/rev/1ce649acf443 Added tag aarch64-shenandoah-jdk8u242-b04 for changeset 7cb8932d8a4f ! .hgtags Changeset: af261f3e6b99 Author: andrew Date: 2019-12-20 09:33 +0000 URL: https://hg.openjdk.java.net/aarch64-port/jdk8u-shenandoah/hotspot/rev/af261f3e6b99 Merge - src/cpu/aarch64/vm/shenandoahBarrierSet_aarch64.cpp - src/cpu/ppc/vm/shenandoahBarrierSet_ppc.cpp - src/cpu/sparc/vm/shenandoahBarrierSet_sparc.cpp - src/cpu/x86/vm/shenandoahBarrierSet_x86.cpp ! src/cpu/x86/vm/stubGenerator_x86_32.cpp ! src/cpu/x86/vm/stubGenerator_x86_64.cpp - src/cpu/zero/vm/shenandoahBarrierSet_zero.cpp - src/share/vm/gc_implementation/shenandoah/shenandoahBrooksPointer.hpp - src/share/vm/gc_implementation/shenandoah/shenandoahBrooksPointer.inline.hpp - src/share/vm/gc_implementation/shenandoah/shenandoahHeapLock.hpp ! src/share/vm/opto/escape.cpp ! src/share/vm/opto/library_call.cpp ! src/share/vm/opto/loopopts.cpp - src/share/vm/opto/shenandoahSupport.cpp - src/share/vm/opto/shenandoahSupport.hpp ! src/share/vm/runtime/stubRoutines.cpp ! src/share/vm/runtime/stubRoutines.hpp ! src/share/vm/runtime/vmStructs.cpp ! src/share/vm/utilities/macros.hpp From Pengfei.Li at arm.com Fri Dec 20 10:21:43 2019 From: Pengfei.Li at arm.com (Pengfei Li) Date: Fri, 20 Dec 2019 10:21:43 +0000 Subject: [aarch64-port-dev ] RFR(M): 8233743: AArch64: Make r27 conditionally allocatable In-Reply-To: <70f2fb20-f72d-07f6-b8ff-7d1e467c3c12@redhat.com> References: <93b1dff3-b760-e305-1422-d21178e9ed75@redhat.com> <28d32c06-9a8e-6f4b-8425-3f07a4fbfe82@redhat.com> <34081dab-0049-dda7-dead-3b2934f8c41b@arm.com> <97c0b309-e911-ff9f-4cea-b6f00bd4962d@redhat.com> <70f2fb20-f72d-07f6-b8ff-7d1e467c3c12@redhat.com> Message-ID: Hi, I'm back for this patch. > That is starting to sound very attractive. With a 64-bit address space I'm > finding it very hard to imagine a scenario in which we don't find a suitable > address. I think AOT-compiled code would still be OK, because it generates > different code, but we'd have to do some testing. Since Nick's recent metaspace reservation fix [1] has completely removed the use of r27, my patch becomes much simpler now. I have removed the condition of UseCompressedClassPointers, rebased the code and created a new webrev. Could you please help review again? Webrev: http://cr.openjdk.java.net/~pli/rfr/8233743/webrev.02/ [1] http://hg.openjdk.java.net/jdk/jdk/rev/dd4b4f273274 -- Thanks, Pengfei From aph at redhat.com Fri Dec 20 11:09:13 2019 From: aph at redhat.com (Andrew Haley) Date: Fri, 20 Dec 2019 12:09:13 +0100 Subject: [aarch64-port-dev ] RFR(M): 8233743: AArch64: Make r27 conditionally allocatable In-Reply-To: References: <93b1dff3-b760-e305-1422-d21178e9ed75@redhat.com> <28d32c06-9a8e-6f4b-8425-3f07a4fbfe82@redhat.com> <34081dab-0049-dda7-dead-3b2934f8c41b@arm.com> <97c0b309-e911-ff9f-4cea-b6f00bd4962d@redhat.com> <70f2fb20-f72d-07f6-b8ff-7d1e467c3c12@redhat.com> Message-ID: <379d9c30-a139-4544-9339-a6ddec913b78@redhat.com> On 12/20/19 10:21 AM, Pengfei Li wrote: > Since Nick's recent metaspace reservation fix [1] has completely removed the use of r27, my patch becomes much simpler now. I have removed the condition of UseCompressedClassPointers, rebased the code and created a new webrev. Could you please help review again? What happens when we use Graal as a replacement for C2, particularly when Graal needs a heap base register? -- Andrew Haley (he/him) Java Platform Lead Engineer Red Hat UK Ltd. https://keybase.io/andrewhaley EAC8 43EB D3EF DB98 CC77 2FAD A5CD 6035 332F A671 From ci_notify at linaro.org Sat Dec 21 12:27:00 2019 From: ci_notify at linaro.org (ci_notify at linaro.org) Date: Sat, 21 Dec 2019 12:27:00 +0000 (UTC) Subject: [aarch64-port-dev ] JTREG, JCStress, SPECjbb2015 and Hadoop/Terasort results for OpenJDK JDK on AArch64 Message-ID: <1451105101.6405.1576931221508.JavaMail.javamailuser@localhost> This is a summary of the JTREG test results =========================================== The build and test results are cycled every 15 days. For detailed information on the test output please refer to: http://openjdk.linaro.org/jdkX/openjdk-jtreg-nightly-tests/summary/2019/354/summary.html ------------------------------------------------------------------------------- client-release/hotspot ------------------------------------------------------------------------------- Build 0: aarch64/2018/oct/15 pass: 5,780; fail: 19; not run: 90 ------------------------------------------------------------------------------- client-release/jdk ------------------------------------------------------------------------------- Build 0: aarch64/2018/oct/15 pass: 8,495; fail: 670; error: 23 ------------------------------------------------------------------------------- client-release/langtools ------------------------------------------------------------------------------- Build 0: aarch64/2018/oct/15 pass: 3,970; fail: 5 ------------------------------------------------------------------------------- release/hotspot ------------------------------------------------------------------------------- Build 0: aarch64/2019/nov/18 pass: 5,750; fail: 1 Build 1: aarch64/2019/nov/20 pass: 5,752 Build 2: aarch64/2019/nov/22 pass: 5,752; fail: 1 Build 3: aarch64/2019/nov/25 pass: 5,752; fail: 1 Build 4: aarch64/2019/nov/27 pass: 5,752; fail: 2 Build 5: aarch64/2019/nov/29 pass: 5,752; fail: 2 Build 6: aarch64/2019/dec/02 pass: 5,753; fail: 4 Build 7: aarch64/2019/dec/04 pass: 5,755; fail: 2 Build 8: aarch64/2019/dec/07 pass: 5,762; fail: 1 Build 9: aarch64/2019/dec/09 pass: 5,762; fail: 1 Build 10: aarch64/2019/dec/11 pass: 5,765; fail: 44 Build 11: aarch64/2019/dec/13 pass: 5,765; fail: 45 Build 12: aarch64/2019/dec/16 pass: 5,764; fail: 45 Build 13: aarch64/2019/dec/18 pass: 5,765; fail: 44 Build 14: aarch64/2019/dec/20 pass: 5,766; fail: 44 ------------------------------------------------------------------------------- release/jdk ------------------------------------------------------------------------------- Build 0: aarch64/2019/nov/18 pass: 8,765; fail: 504; error: 18 Build 1: aarch64/2019/nov/20 pass: 8,768; fail: 504; error: 19 Build 2: aarch64/2019/nov/22 pass: 8,769; fail: 507; error: 18 Build 3: aarch64/2019/nov/25 pass: 8,775; fail: 509; error: 17 Build 4: aarch64/2019/nov/27 pass: 8,779; fail: 506; error: 22 Build 5: aarch64/2019/nov/29 pass: 8,784; fail: 503; error: 20 Build 6: aarch64/2019/dec/02 pass: 8,784; fail: 507; error: 19 Build 7: aarch64/2019/dec/04 pass: 8,788; fail: 505; error: 17 Build 8: aarch64/2019/dec/07 pass: 8,819; fail: 524; error: 17 Build 9: aarch64/2019/dec/09 pass: 8,820; fail: 519; error: 21 Build 10: aarch64/2019/dec/11 pass: 8,818; fail: 520; error: 18 Build 11: aarch64/2019/dec/13 pass: 8,811; fail: 530; error: 17 Build 12: aarch64/2019/dec/16 pass: 8,813; fail: 529; error: 17 Build 13: aarch64/2019/dec/18 pass: 8,827; fail: 520; error: 16 Build 14: aarch64/2019/dec/20 pass: 8,818; fail: 528; error: 20 2 fatal errors were detected; please follow the link above for more detail. ------------------------------------------------------------------------------- release/langtools ------------------------------------------------------------------------------- Build 0: aarch64/2019/nov/18 pass: 3,981 Build 1: aarch64/2019/nov/20 pass: 3,981 Build 2: aarch64/2019/nov/22 pass: 3,981 Build 3: aarch64/2019/nov/25 pass: 3,983 Build 4: aarch64/2019/nov/27 pass: 4,006 Build 5: aarch64/2019/nov/29 pass: 4,006 Build 6: aarch64/2019/dec/02 pass: 4,002; fail: 5; error: 1 Build 7: aarch64/2019/dec/04 pass: 4,008 Build 8: aarch64/2019/dec/07 pass: 4,019 Build 9: aarch64/2019/dec/09 pass: 4,019 Build 10: aarch64/2019/dec/11 pass: 4,021 Build 11: aarch64/2019/dec/13 pass: 4,029 Build 12: aarch64/2019/dec/16 pass: 4,030 Build 13: aarch64/2019/dec/18 pass: 4,030 Build 14: aarch64/2019/dec/20 pass: 4,030 ------------------------------------------------------------------------------- server-release/hotspot ------------------------------------------------------------------------------- Build 0: aarch64/2018/oct/15 pass: 5,787; fail: 18; not run: 90 ------------------------------------------------------------------------------- server-release/jdk ------------------------------------------------------------------------------- Build 0: aarch64/2018/oct/15 pass: 8,476; fail: 686; error: 27 ------------------------------------------------------------------------------- server-release/langtools ------------------------------------------------------------------------------- Build 0: aarch64/2018/oct/15 pass: 3,970; fail: 5 Previous results can be found here: http://openjdk.linaro.org/jdkX/openjdk-jtreg-nightly-tests/index.html SPECjbb2015 composite regression test completed =============================================== This test measures the relative performance of the server compiler running the SPECjbb2015 composite tests and compares the performance against the baseline performance of the server compiler taken on 2016-11-21. In accordance with [1], the SPECjbb2015 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): 8.13x Relative performance: Server critical-jOPS (nc): 12.67x Details of the test setup and historical results may be found here: http://openjdk.linaro.org/jdkX/SPECjbb2015-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 server compiler on 2014-04-01. Relative performance: Zero: 1.0, Server: 207.57 Server 207.57 / Server 2014-04-01 (71.00): 2.92x Details of the test setup and historical results may be found here: http://openjdk.linaro.org/jdkX/hadoop-terasort-benchmark-results/ This is a summary of the jcstress test results ============================================== The build and test results are cycled every 15 days. 2019-11-19 pass rate: 10490/10490, results: http://openjdk.linaro.org/jdkX/jcstress-nightly-runs/2019/322/results/ 2019-11-21 pass rate: 10490/10490, results: http://openjdk.linaro.org/jdkX/jcstress-nightly-runs/2019/324/results/ 2019-11-23 pass rate: 10490/10490, results: http://openjdk.linaro.org/jdkX/jcstress-nightly-runs/2019/326/results/ 2019-11-26 pass rate: 10490/10490, results: http://openjdk.linaro.org/jdkX/jcstress-nightly-runs/2019/329/results/ 2019-12-03 pass rate: 10490/10490, results: http://openjdk.linaro.org/jdkX/jcstress-nightly-runs/2019/331/results/ 2019-12-04 pass rate: 10490/10490, results: http://openjdk.linaro.org/jdkX/jcstress-nightly-runs/2019/333/results/ 2019-12-05 pass rate: 10490/10490, results: http://openjdk.linaro.org/jdkX/jcstress-nightly-runs/2019/336/results/ 2019-12-07 pass rate: 10490/10490, results: http://openjdk.linaro.org/jdkX/jcstress-nightly-runs/2019/338/results/ 2019-12-08 pass rate: 10490/10490, results: http://openjdk.linaro.org/jdkX/jcstress-nightly-runs/2019/341/results/ 2019-12-10 pass rate: 10490/10490, results: http://openjdk.linaro.org/jdkX/jcstress-nightly-runs/2019/343/results/ 2019-12-12 pass rate: 10490/10490, results: http://openjdk.linaro.org/jdkX/jcstress-nightly-runs/2019/345/results/ 2019-12-14 pass rate: 10490/10490, results: http://openjdk.linaro.org/jdkX/jcstress-nightly-runs/2019/347/results/ 2019-12-17 pass rate: 10490/10490, results: http://openjdk.linaro.org/jdkX/jcstress-nightly-runs/2019/350/results/ 2019-12-19 pass rate: 10490/10490, results: http://openjdk.linaro.org/jdkX/jcstress-nightly-runs/2019/352/results/ 2019-12-21 pass rate: 10490/10490, results: http://openjdk.linaro.org/jdkX/jcstress-nightly-runs/2019/354/results/ For detailed information on the test output please refer to: http://openjdk.linaro.org/jdkX/jcstress-nightly-runs/ From ci_notify at linaro.org Sun Dec 22 14:03:58 2019 From: ci_notify at linaro.org (ci_notify at linaro.org) Date: Sun, 22 Dec 2019 14:03:58 +0000 (UTC) Subject: [aarch64-port-dev ] JTREG, JCStress, SPECjbb2015 and Hadoop/Terasort results for OpenJDK 11u on AArch64 Message-ID: <1636129846.6756.1577023438912.JavaMail.javamailuser@localhost> This is a summary of the JTREG test results =========================================== The build and test results are cycled every 15 days. For detailed information on the test output please refer to: http://openjdk.linaro.org/jdk11u/openjdk-jtreg-nightly-tests/summary/2019/355/summary.html ------------------------------------------------------------------------------- release/hotspot ------------------------------------------------------------------------------- Build 0: aarch64/2019/sep/05 pass: 5,764; fail: 2 Build 1: aarch64/2019/sep/10 pass: 5,764; fail: 2 Build 2: aarch64/2019/sep/17 pass: 5,763; fail: 3 Build 3: aarch64/2019/sep/21 pass: 5,764; fail: 2 Build 4: aarch64/2019/oct/04 pass: 5,764; fail: 2 Build 5: aarch64/2019/oct/17 pass: 5,764; fail: 2 Build 6: aarch64/2019/oct/31 pass: 5,784; fail: 1 Build 7: aarch64/2019/nov/09 pass: 5,773; fail: 3 Build 8: aarch64/2019/nov/16 pass: 5,775; fail: 1 Build 9: aarch64/2019/nov/21 pass: 5,775; fail: 1 Build 10: aarch64/2019/dec/05 pass: 5,775; fail: 1 Build 11: aarch64/2019/dec/08 pass: 5,775; fail: 1 Build 12: aarch64/2019/dec/14 pass: 5,775; fail: 1 Build 13: aarch64/2019/dec/17 pass: 5,775; fail: 1 Build 14: aarch64/2019/dec/21 pass: 5,775; fail: 1 ------------------------------------------------------------------------------- release/jdk ------------------------------------------------------------------------------- Build 0: aarch64/2019/sep/05 pass: 8,465; fail: 479; error: 14 Build 1: aarch64/2019/sep/10 pass: 8,444; fail: 500; error: 14 Build 2: aarch64/2019/sep/17 pass: 8,462; fail: 482; error: 12 Build 3: aarch64/2019/sep/21 pass: 8,467; fail: 478; error: 13 Build 4: aarch64/2019/oct/04 pass: 8,444; fail: 498; error: 16 Build 5: aarch64/2019/oct/17 pass: 8,452; fail: 493; error: 16 Build 6: aarch64/2019/oct/31 pass: 8,468; fail: 490; error: 14 Build 7: aarch64/2019/nov/09 pass: 8,487; fail: 470; error: 16 Build 8: aarch64/2019/nov/16 pass: 8,475; fail: 484; error: 15 Build 9: aarch64/2019/nov/21 pass: 8,489; fail: 497; error: 13 Build 10: aarch64/2019/dec/05 pass: 8,492; fail: 501; error: 11 Build 11: aarch64/2019/dec/08 pass: 8,482; fail: 505; error: 17 Build 12: aarch64/2019/dec/14 pass: 8,512; fail: 481; error: 12 Build 13: aarch64/2019/dec/17 pass: 8,485; fail: 505; error: 15 Build 14: aarch64/2019/dec/21 pass: 8,499; fail: 496; error: 10 2 fatal errors were detected; please follow the link above for more detail. ------------------------------------------------------------------------------- release/langtools ------------------------------------------------------------------------------- Build 0: aarch64/2019/sep/05 pass: 3,910 Build 1: aarch64/2019/sep/10 pass: 3,910 Build 2: aarch64/2019/sep/17 pass: 3,910 Build 3: aarch64/2019/sep/21 pass: 3,910 Build 4: aarch64/2019/oct/04 pass: 3,910 Build 5: aarch64/2019/oct/17 pass: 3,910 Build 6: aarch64/2019/oct/31 pass: 3,910 Build 7: aarch64/2019/nov/09 pass: 3,910 Build 8: aarch64/2019/nov/16 pass: 3,910 Build 9: aarch64/2019/nov/21 pass: 3,910 Build 10: aarch64/2019/dec/05 pass: 3,910 Build 11: aarch64/2019/dec/08 pass: 3,910 Build 12: aarch64/2019/dec/14 pass: 3,910 Build 13: aarch64/2019/dec/17 pass: 3,910 Build 14: aarch64/2019/dec/21 pass: 3,910 Previous results can be found here: http://openjdk.linaro.org/jdk11u/openjdk-jtreg-nightly-tests/index.html SPECjbb2015 composite regression test completed =============================================== This test measures the relative performance of the server compiler running the SPECjbb2015 composite tests and compares the performance against the baseline performance of the server compiler taken on 2016-11-21. In accordance with [1], the SPECjbb2015 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): 7.46x Relative performance: Server critical-jOPS (nc): 7.83x Details of the test setup and historical results may be found here: http://openjdk.linaro.org/jdk11u/SPECjbb2015-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 server compiler on 2014-04-01. Relative performance: Zero: 1.0, Server: 210.67 Server 210.67 / Server 2014-04-01 (71.00): 2.97x Details of the test setup and historical results may be found here: http://openjdk.linaro.org/jdk11u/hadoop-terasort-benchmark-results/ This is a summary of the jcstress test results ============================================== The build and test results are cycled every 15 days. 2019-09-07 pass rate: 10489/10489, results: http://openjdk.linaro.org/jdk11u/jcstress-nightly-runs/2019/248/results/ 2019-09-11 pass rate: 10489/10489, results: http://openjdk.linaro.org/jdk11u/jcstress-nightly-runs/2019/253/results/ 2019-09-18 pass rate: 10489/10489, results: http://openjdk.linaro.org/jdk11u/jcstress-nightly-runs/2019/260/results/ 2019-09-22 pass rate: 10489/10489, results: http://openjdk.linaro.org/jdk11u/jcstress-nightly-runs/2019/264/results/ 2019-10-05 pass rate: 10489/10489, results: http://openjdk.linaro.org/jdk11u/jcstress-nightly-runs/2019/277/results/ 2019-10-18 pass rate: 10489/10489, results: http://openjdk.linaro.org/jdk11u/jcstress-nightly-runs/2019/290/results/ 2019-11-01 pass rate: 10489/10489, results: http://openjdk.linaro.org/jdk11u/jcstress-nightly-runs/2019/304/results/ 2019-11-10 pass rate: 10490/10490, results: http://openjdk.linaro.org/jdk11u/jcstress-nightly-runs/2019/313/results/ 2019-11-17 pass rate: 10490/10490, results: http://openjdk.linaro.org/jdk11u/jcstress-nightly-runs/2019/320/results/ 2019-11-22 pass rate: 10490/10490, results: http://openjdk.linaro.org/jdk11u/jcstress-nightly-runs/2019/325/results/ 2019-12-07 pass rate: 10490/10490, results: http://openjdk.linaro.org/jdk11u/jcstress-nightly-runs/2019/339/results/ 2019-12-09 pass rate: 10490/10490, results: http://openjdk.linaro.org/jdk11u/jcstress-nightly-runs/2019/342/results/ 2019-12-15 pass rate: 10490/10490, results: http://openjdk.linaro.org/jdk11u/jcstress-nightly-runs/2019/348/results/ 2019-12-18 pass rate: 10490/10490, results: http://openjdk.linaro.org/jdk11u/jcstress-nightly-runs/2019/351/results/ 2019-12-22 pass rate: 10490/10490, results: http://openjdk.linaro.org/jdk11u/jcstress-nightly-runs/2019/355/results/ For detailed information on the test output please refer to: http://openjdk.linaro.org/jdk11u/jcstress-nightly-runs/ From ci_notify at linaro.org Sun Dec 22 14:07:22 2019 From: ci_notify at linaro.org (ci_notify at linaro.org) Date: Sun, 22 Dec 2019 14:07:22 +0000 (UTC) Subject: [aarch64-port-dev ] JTREG, JCStress, SPECjbb2015 and Hadoop/Terasort results for OpenJDK 8u on AArch64 Message-ID: <403905558.6758.1577023643502.JavaMail.javamailuser@localhost> This is a summary of the JTREG test results =========================================== The build and test results are cycled every 15 days. For detailed information on the test output please refer to: http://openjdk.linaro.org/jdk8u/openjdk-jtreg-nightly-tests/summary/2019/355/summary.html ------------------------------------------------------------------------------- release/hotspot ------------------------------------------------------------------------------- Build 0: aarch64/2019/aug/06 pass: 799; fail: 29; error: 12 Build 1: aarch64/2019/aug/08 pass: 830; fail: 9; error: 1 Build 2: aarch64/2019/aug/11 pass: 825; fail: 14; error: 1 Build 3: aarch64/2019/aug/13 pass: 830; fail: 9; error: 1 Build 4: aarch64/2019/aug/15 pass: 837; fail: 9; error: 1 Build 5: aarch64/2019/aug/17 pass: 837; fail: 9; error: 1 Build 6: aarch64/2019/aug/22 pass: 837; fail: 9; error: 1 Build 7: aarch64/2019/sep/10 pass: 838; fail: 13; error: 1 Build 8: aarch64/2019/sep/21 pass: 838; fail: 13; error: 1 Build 9: aarch64/2019/nov/02 pass: 843; fail: 9; error: 1 Build 10: aarch64/2019/nov/14 pass: 843; fail: 9; error: 1 Build 11: aarch64/2019/dec/16 pass: 843; fail: 10; error: 1 Build 12: aarch64/2019/dec/17 pass: 846; fail: 10; error: 2 Build 13: aarch64/2019/dec/19 pass: 846; fail: 10; error: 2 Build 14: aarch64/2019/dec/21 pass: 848; fail: 10; error: 2 ------------------------------------------------------------------------------- release/jdk ------------------------------------------------------------------------------- Build 0: aarch64/2019/aug/06 pass: 5,945; fail: 275; error: 23 Build 1: aarch64/2019/aug/08 pass: 5,953; fail: 267; error: 23 Build 2: aarch64/2019/aug/11 pass: 5,947; fail: 272; error: 25 Build 3: aarch64/2019/aug/13 pass: 5,962; fail: 258; error: 24 Build 4: aarch64/2019/aug/15 pass: 5,955; fail: 266; error: 23 Build 5: aarch64/2019/aug/17 pass: 5,951; fail: 269; error: 24 Build 6: aarch64/2019/aug/22 pass: 5,945; fail: 279; error: 20 Build 7: aarch64/2019/sep/10 pass: 5,951; fail: 273; error: 23 Build 8: aarch64/2019/sep/21 pass: 5,964; fail: 261; error: 22 Build 9: aarch64/2019/nov/02 pass: 5,956; fail: 278; error: 18 Build 10: aarch64/2019/nov/14 pass: 5,956; fail: 275; error: 21 Build 11: aarch64/2019/dec/16 pass: 5,964; fail: 267; error: 21 Build 12: aarch64/2019/dec/17 pass: 5,963; fail: 267; error: 22 Build 13: aarch64/2019/dec/19 pass: 5,959; fail: 272; error: 21 Build 14: aarch64/2019/dec/21 pass: 5,970; fail: 262; error: 21 1 fatal errors were detected; please follow the link above for more detail. ------------------------------------------------------------------------------- release/langtools ------------------------------------------------------------------------------- Build 0: aarch64/2019/aug/06 pass: 3,116; fail: 2 Build 1: aarch64/2019/aug/08 pass: 3,116; fail: 2 Build 2: aarch64/2019/aug/11 pass: 3,116; fail: 2 Build 3: aarch64/2019/aug/13 pass: 3,116; fail: 2 Build 4: aarch64/2019/aug/15 pass: 3,116; fail: 2 Build 5: aarch64/2019/aug/17 pass: 3,116; fail: 2 Build 6: aarch64/2019/aug/22 pass: 3,116; fail: 2 Build 7: aarch64/2019/sep/10 pass: 3,116; fail: 2 Build 8: aarch64/2019/sep/21 pass: 3,116; fail: 2 Build 9: aarch64/2019/nov/02 pass: 3,116; fail: 2 Build 10: aarch64/2019/nov/14 pass: 3,116; fail: 2 Build 11: aarch64/2019/dec/16 pass: 3,116; fail: 2 Build 12: aarch64/2019/dec/17 pass: 3,117; fail: 2 Build 13: aarch64/2019/dec/19 pass: 3,117; fail: 2 Build 14: aarch64/2019/dec/21 pass: 3,117; fail: 2 Previous results can be found here: http://openjdk.linaro.org/jdk8u/openjdk-jtreg-nightly-tests/index.html SPECjbb2015 composite regression test completed =============================================== This test measures the relative performance of the server compiler running the SPECjbb2015 composite tests and compares the performance against the baseline performance of the server compiler taken on 2016-11-21. In accordance with [1], the SPECjbb2015 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): 6.73x Relative performance: Server critical-jOPS (nc): 8.70x Details of the test setup and historical results may be found here: http://openjdk.linaro.org/jdk8u/SPECjbb2015-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 server compiler on 2014-04-01. Relative performance: Zero: 1.0, Server: 174.26 Server 174.26 / Server 2014-04-01 (71.00): 2.45x Details of the test setup and historical results may be found here: http://openjdk.linaro.org/jdk8u/hadoop-terasort-benchmark-results/ This is a summary of the jcstress test results ============================================== The build and test results are cycled every 15 days. 2019-08-07 pass rate: 8229/8229, results: http://openjdk.linaro.org/jdk8u/jcstress-nightly-runs/2019/218/results/ 2019-08-09 pass rate: 8229/8229, results: http://openjdk.linaro.org/jdk8u/jcstress-nightly-runs/2019/220/results/ 2019-08-12 pass rate: 8230/8230, results: http://openjdk.linaro.org/jdk8u/jcstress-nightly-runs/2019/223/results/ 2019-08-13 pass rate: 8230/8230, results: http://openjdk.linaro.org/jdk8u/jcstress-nightly-runs/2019/225/results/ 2019-08-16 pass rate: 8230/8230, results: http://openjdk.linaro.org/jdk8u/jcstress-nightly-runs/2019/227/results/ 2019-08-17 pass rate: 8230/8230, results: http://openjdk.linaro.org/jdk8u/jcstress-nightly-runs/2019/229/results/ 2019-08-23 pass rate: 8230/8230, results: http://openjdk.linaro.org/jdk8u/jcstress-nightly-runs/2019/234/results/ 2019-09-11 pass rate: 8230/8230, results: http://openjdk.linaro.org/jdk8u/jcstress-nightly-runs/2019/253/results/ 2019-09-22 pass rate: 8230/8230, results: http://openjdk.linaro.org/jdk8u/jcstress-nightly-runs/2019/264/results/ 2019-11-02 pass rate: 8230/8230, results: http://openjdk.linaro.org/jdk8u/jcstress-nightly-runs/2019/306/results/ 2019-11-15 pass rate: 8231/8231, results: http://openjdk.linaro.org/jdk8u/jcstress-nightly-runs/2019/318/results/ 2019-12-16 pass rate: 8231/8231, results: http://openjdk.linaro.org/jdk8u/jcstress-nightly-runs/2019/350/results/ 2019-12-18 pass rate: 8231/8231, results: http://openjdk.linaro.org/jdk8u/jcstress-nightly-runs/2019/351/results/ 2019-12-19 pass rate: 8231/8231, results: http://openjdk.linaro.org/jdk8u/jcstress-nightly-runs/2019/353/results/ 2019-12-22 pass rate: 8231/8231, results: http://openjdk.linaro.org/jdk8u/jcstress-nightly-runs/2019/355/results/ For detailed information on the test output please refer to: http://openjdk.linaro.org/jdk8u/jcstress-nightly-runs/ From Pengfei.Li at arm.com Mon Dec 23 07:53:52 2019 From: Pengfei.Li at arm.com (Pengfei Li) Date: Mon, 23 Dec 2019 07:53:52 +0000 Subject: [aarch64-port-dev ] RFR(M): 8233743: AArch64: Make r27 conditionally allocatable In-Reply-To: <379d9c30-a139-4544-9339-a6ddec913b78@redhat.com> References: <93b1dff3-b760-e305-1422-d21178e9ed75@redhat.com> <28d32c06-9a8e-6f4b-8425-3f07a4fbfe82@redhat.com> <34081dab-0049-dda7-dead-3b2934f8c41b@arm.com> <97c0b309-e911-ff9f-4cea-b6f00bd4962d@redhat.com> <70f2fb20-f72d-07f6-b8ff-7d1e467c3c12@redhat.com> <379d9c30-a139-4544-9339-a6ddec913b78@redhat.com> Message-ID: Hi Andrew, > On 12/20/19 10:21 AM, Pengfei Li wrote: > > Since Nick's recent metaspace reservation fix [1] has completely removed > the use of r27, my patch becomes much simpler now. I have removed the > condition of UseCompressedClassPointers, rebased the code and created a > new webrev. Could you please help review again? > > What happens when we use Graal as a replacement for C2, particularly when > Graal needs a heap base register? Regarding your question, the Graal compiler (particularly on AArch64) uses r27 for compressing and uncompressing oops. Neither compressing nor uncompressing klass pointers uses r27. See code at [1], [2]. In Graal, we also wanted to make the heap base register allocatable when UseCompressedOops is off. Since before, AArch64 HotSpot didn't support r27 as an allocatable register, Graal patch e4d9c5f [3] marked r27 as non-allocatable and JVMCI patch JDK-8231754 [4] reserved r27 unconditionally. That's why I would like to revert JDK-8231754 in my patch. [1] https://github.com/oracle/graal/blob/master/compiler/src/org.graalvm.compiler.hotspot.aarch64/src/org/graalvm/compiler/hotspot/aarch64/AArch64HotSpotLIRGenerator.java#L256 [2] https://github.com/oracle/graal/blob/master/compiler/src/org.graalvm.compiler.hotspot.aarch64/src/org/graalvm/compiler/hotspot/aarch64/AArch64HotSpotLIRGenerator.java#L286 [3] https://github.com/oracle/graal/commit/e4d9c5f09a3c9be9f3c66ff0feff787519875a12 [4] http://hg.openjdk.java.net/jdk/jdk/rev/d068b1e534de -- Thanks, Pengfei From aph at redhat.com Mon Dec 23 09:43:16 2019 From: aph at redhat.com (Andrew Haley) Date: Mon, 23 Dec 2019 10:43:16 +0100 Subject: [aarch64-port-dev ] RFR(M): 8233743: AArch64: Make r27 conditionally allocatable In-Reply-To: References: <93b1dff3-b760-e305-1422-d21178e9ed75@redhat.com> <28d32c06-9a8e-6f4b-8425-3f07a4fbfe82@redhat.com> <34081dab-0049-dda7-dead-3b2934f8c41b@arm.com> <97c0b309-e911-ff9f-4cea-b6f00bd4962d@redhat.com> <70f2fb20-f72d-07f6-b8ff-7d1e467c3c12@redhat.com> <379d9c30-a139-4544-9339-a6ddec913b78@redhat.com> Message-ID: <57e85dcb-0d1c-135f-27dd-ec81534f0ad6@redhat.com> On 12/23/19 8:53 AM, Pengfei Li wrote: > Regarding your question, the Graal compiler (particularly on AArch64) uses r27 for compressing and uncompressing oops. Neither compressing nor uncompressing klass pointers uses r27. See code at [1], [2]. > > In Graal, we also wanted to make the heap base register allocatable when UseCompressedOops is off. Since before, AArch64 HotSpot didn't support r27 as an allocatable register, Graal patch e4d9c5f [3] marked r27 as non-allocatable and JVMCI patch JDK-8231754 [4] reserved r27 unconditionally. That's why I would like to revert JDK-8231754 in my patch. > > [1] https://github.com/oracle/graal/blob/master/compiler/src/org.graalvm.compiler.hotspot.aarch64/src/org/graalvm/compiler/hotspot/aarch64/AArch64HotSpotLIRGenerator.java#L256 > [2] https://github.com/oracle/graal/blob/master/compiler/src/org.graalvm.compiler.hotspot.aarch64/src/org/graalvm/compiler/hotspot/aarch64/AArch64HotSpotLIRGenerator.java#L286 > [3] https://github.com/oracle/graal/commit/e4d9c5f09a3c9be9f3c66ff0feff787519875a12 > [4] http://hg.openjdk.java.net/jdk/jdk/rev/d068b1e534de OK. As long as you've fully tested Graal with UseJVMCICompiler after this patch was applied I'm happy. -- Andrew Haley (he/him) Java Platform Lead Engineer Red Hat UK Ltd. https://keybase.io/andrewhaley EAC8 43EB D3EF DB98 CC77 2FAD A5CD 6035 332F A671 From ci_notify at linaro.org Tue Dec 24 12:49:21 2019 From: ci_notify at linaro.org (ci_notify at linaro.org) Date: Tue, 24 Dec 2019 12:49:21 +0000 (UTC) Subject: [aarch64-port-dev ] JTREG, JCStress, SPECjbb2015 and Hadoop/Terasort results for OpenJDK JDK on AArch64 Message-ID: <149335537.7431.1577191762307.JavaMail.javamailuser@localhost> This is a summary of the JTREG test results =========================================== The build and test results are cycled every 15 days. For detailed information on the test output please refer to: http://openjdk.linaro.org/jdkX/openjdk-jtreg-nightly-tests/summary/2019/357/summary.html ------------------------------------------------------------------------------- client-release/hotspot ------------------------------------------------------------------------------- Build 0: aarch64/2018/oct/15 pass: 5,780; fail: 19; not run: 90 ------------------------------------------------------------------------------- client-release/jdk ------------------------------------------------------------------------------- Build 0: aarch64/2018/oct/15 pass: 8,495; fail: 670; error: 23 ------------------------------------------------------------------------------- client-release/langtools ------------------------------------------------------------------------------- Build 0: aarch64/2018/oct/15 pass: 3,970; fail: 5 ------------------------------------------------------------------------------- release/hotspot ------------------------------------------------------------------------------- Build 0: aarch64/2019/nov/20 pass: 5,752 Build 1: aarch64/2019/nov/22 pass: 5,752; fail: 1 Build 2: aarch64/2019/nov/25 pass: 5,752; fail: 1 Build 3: aarch64/2019/nov/27 pass: 5,752; fail: 2 Build 4: aarch64/2019/nov/29 pass: 5,752; fail: 2 Build 5: aarch64/2019/dec/02 pass: 5,753; fail: 4 Build 6: aarch64/2019/dec/04 pass: 5,755; fail: 2 Build 7: aarch64/2019/dec/07 pass: 5,762; fail: 1 Build 8: aarch64/2019/dec/09 pass: 5,762; fail: 1 Build 9: aarch64/2019/dec/11 pass: 5,765; fail: 44 Build 10: aarch64/2019/dec/13 pass: 5,765; fail: 45 Build 11: aarch64/2019/dec/16 pass: 5,764; fail: 45 Build 12: aarch64/2019/dec/18 pass: 5,765; fail: 44 Build 13: aarch64/2019/dec/20 pass: 5,766; fail: 44 Build 14: aarch64/2019/dec/23 pass: 5,766; fail: 44 ------------------------------------------------------------------------------- release/jdk ------------------------------------------------------------------------------- Build 0: aarch64/2019/nov/20 pass: 8,768; fail: 504; error: 19 Build 1: aarch64/2019/nov/22 pass: 8,769; fail: 507; error: 18 Build 2: aarch64/2019/nov/25 pass: 8,775; fail: 509; error: 17 Build 3: aarch64/2019/nov/27 pass: 8,779; fail: 506; error: 22 Build 4: aarch64/2019/nov/29 pass: 8,784; fail: 503; error: 20 Build 5: aarch64/2019/dec/02 pass: 8,784; fail: 507; error: 19 Build 6: aarch64/2019/dec/04 pass: 8,788; fail: 505; error: 17 Build 7: aarch64/2019/dec/07 pass: 8,819; fail: 524; error: 17 Build 8: aarch64/2019/dec/09 pass: 8,820; fail: 519; error: 21 Build 9: aarch64/2019/dec/11 pass: 8,818; fail: 520; error: 18 Build 10: aarch64/2019/dec/13 pass: 8,811; fail: 530; error: 17 Build 11: aarch64/2019/dec/16 pass: 8,813; fail: 529; error: 17 Build 12: aarch64/2019/dec/18 pass: 8,827; fail: 520; error: 16 Build 13: aarch64/2019/dec/20 pass: 8,818; fail: 528; error: 20 Build 14: aarch64/2019/dec/23 pass: 8,823; fail: 524; error: 20 3 fatal errors were detected; please follow the link above for more detail. ------------------------------------------------------------------------------- release/langtools ------------------------------------------------------------------------------- Build 0: aarch64/2019/nov/20 pass: 3,981 Build 1: aarch64/2019/nov/22 pass: 3,981 Build 2: aarch64/2019/nov/25 pass: 3,983 Build 3: aarch64/2019/nov/27 pass: 4,006 Build 4: aarch64/2019/nov/29 pass: 4,006 Build 5: aarch64/2019/dec/02 pass: 4,002; fail: 5; error: 1 Build 6: aarch64/2019/dec/04 pass: 4,008 Build 7: aarch64/2019/dec/07 pass: 4,019 Build 8: aarch64/2019/dec/09 pass: 4,019 Build 9: aarch64/2019/dec/11 pass: 4,021 Build 10: aarch64/2019/dec/13 pass: 4,029 Build 11: aarch64/2019/dec/16 pass: 4,030 Build 12: aarch64/2019/dec/18 pass: 4,030 Build 13: aarch64/2019/dec/20 pass: 4,030 Build 14: aarch64/2019/dec/23 pass: 4,030 ------------------------------------------------------------------------------- server-release/hotspot ------------------------------------------------------------------------------- Build 0: aarch64/2018/oct/15 pass: 5,787; fail: 18; not run: 90 ------------------------------------------------------------------------------- server-release/jdk ------------------------------------------------------------------------------- Build 0: aarch64/2018/oct/15 pass: 8,476; fail: 686; error: 27 ------------------------------------------------------------------------------- server-release/langtools ------------------------------------------------------------------------------- Build 0: aarch64/2018/oct/15 pass: 3,970; fail: 5 Previous results can be found here: http://openjdk.linaro.org/jdkX/openjdk-jtreg-nightly-tests/index.html SPECjbb2015 composite regression test completed =============================================== This test measures the relative performance of the server compiler running the SPECjbb2015 composite tests and compares the performance against the baseline performance of the server compiler taken on 2016-11-21. In accordance with [1], the SPECjbb2015 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): 8.04x Relative performance: Server critical-jOPS (nc): 11.99x Details of the test setup and historical results may be found here: http://openjdk.linaro.org/jdkX/SPECjbb2015-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 server compiler on 2014-04-01. Relative performance: Zero: 1.0, Server: 210.67 Server 210.67 / Server 2014-04-01 (71.00): 2.97x Details of the test setup and historical results may be found here: http://openjdk.linaro.org/jdkX/hadoop-terasort-benchmark-results/ This is a summary of the jcstress test results ============================================== The build and test results are cycled every 15 days. 2019-11-21 pass rate: 10490/10490, results: http://openjdk.linaro.org/jdkX/jcstress-nightly-runs/2019/324/results/ 2019-11-23 pass rate: 10490/10490, results: http://openjdk.linaro.org/jdkX/jcstress-nightly-runs/2019/326/results/ 2019-11-26 pass rate: 10490/10490, results: http://openjdk.linaro.org/jdkX/jcstress-nightly-runs/2019/329/results/ 2019-12-03 pass rate: 10490/10490, results: http://openjdk.linaro.org/jdkX/jcstress-nightly-runs/2019/331/results/ 2019-12-04 pass rate: 10490/10490, results: http://openjdk.linaro.org/jdkX/jcstress-nightly-runs/2019/333/results/ 2019-12-05 pass rate: 10490/10490, results: http://openjdk.linaro.org/jdkX/jcstress-nightly-runs/2019/336/results/ 2019-12-07 pass rate: 10490/10490, results: http://openjdk.linaro.org/jdkX/jcstress-nightly-runs/2019/338/results/ 2019-12-08 pass rate: 10490/10490, results: http://openjdk.linaro.org/jdkX/jcstress-nightly-runs/2019/341/results/ 2019-12-10 pass rate: 10490/10490, results: http://openjdk.linaro.org/jdkX/jcstress-nightly-runs/2019/343/results/ 2019-12-12 pass rate: 10490/10490, results: http://openjdk.linaro.org/jdkX/jcstress-nightly-runs/2019/345/results/ 2019-12-14 pass rate: 10490/10490, results: http://openjdk.linaro.org/jdkX/jcstress-nightly-runs/2019/347/results/ 2019-12-17 pass rate: 10490/10490, results: http://openjdk.linaro.org/jdkX/jcstress-nightly-runs/2019/350/results/ 2019-12-19 pass rate: 10490/10490, results: http://openjdk.linaro.org/jdkX/jcstress-nightly-runs/2019/352/results/ 2019-12-21 pass rate: 10490/10490, results: http://openjdk.linaro.org/jdkX/jcstress-nightly-runs/2019/354/results/ 2019-12-24 pass rate: 10490/10490, results: http://openjdk.linaro.org/jdkX/jcstress-nightly-runs/2019/357/results/ For detailed information on the test output please refer to: http://openjdk.linaro.org/jdkX/jcstress-nightly-runs/ From ci_notify at linaro.org Thu Dec 26 12:13:35 2019 From: ci_notify at linaro.org (ci_notify at linaro.org) Date: Thu, 26 Dec 2019 12:13:35 +0000 (UTC) Subject: [aarch64-port-dev ] JTREG, JCStress, SPECjbb2015 and Hadoop/Terasort results for OpenJDK JDK on AArch64 Message-ID: <1743190654.8136.1577362416434.JavaMail.javamailuser@localhost> This is a summary of the JTREG test results =========================================== The build and test results are cycled every 15 days. For detailed information on the test output please refer to: http://openjdk.linaro.org/jdkX/openjdk-jtreg-nightly-tests/summary/2019/359/summary.html ------------------------------------------------------------------------------- client-release/hotspot ------------------------------------------------------------------------------- Build 0: aarch64/2018/oct/15 pass: 5,780; fail: 19; not run: 90 ------------------------------------------------------------------------------- client-release/jdk ------------------------------------------------------------------------------- Build 0: aarch64/2018/oct/15 pass: 8,495; fail: 670; error: 23 ------------------------------------------------------------------------------- client-release/langtools ------------------------------------------------------------------------------- Build 0: aarch64/2018/oct/15 pass: 3,970; fail: 5 ------------------------------------------------------------------------------- release/hotspot ------------------------------------------------------------------------------- Build 0: aarch64/2019/nov/22 pass: 5,752; fail: 1 Build 1: aarch64/2019/nov/25 pass: 5,752; fail: 1 Build 2: aarch64/2019/nov/27 pass: 5,752; fail: 2 Build 3: aarch64/2019/nov/29 pass: 5,752; fail: 2 Build 4: aarch64/2019/dec/02 pass: 5,753; fail: 4 Build 5: aarch64/2019/dec/04 pass: 5,755; fail: 2 Build 6: aarch64/2019/dec/07 pass: 5,762; fail: 1 Build 7: aarch64/2019/dec/09 pass: 5,762; fail: 1 Build 8: aarch64/2019/dec/11 pass: 5,765; fail: 44 Build 9: aarch64/2019/dec/13 pass: 5,765; fail: 45 Build 10: aarch64/2019/dec/16 pass: 5,764; fail: 45 Build 11: aarch64/2019/dec/18 pass: 5,765; fail: 44 Build 12: aarch64/2019/dec/20 pass: 5,766; fail: 44 Build 13: aarch64/2019/dec/23 pass: 5,766; fail: 44 Build 14: aarch64/2019/dec/25 pass: 5,765; fail: 46 2 fatal errors were detected; please follow the link above for more detail. ------------------------------------------------------------------------------- release/jdk ------------------------------------------------------------------------------- Build 0: aarch64/2019/nov/22 pass: 8,769; fail: 507; error: 18 Build 1: aarch64/2019/nov/25 pass: 8,775; fail: 509; error: 17 Build 2: aarch64/2019/nov/27 pass: 8,779; fail: 506; error: 22 Build 3: aarch64/2019/nov/29 pass: 8,784; fail: 503; error: 20 Build 4: aarch64/2019/dec/02 pass: 8,784; fail: 507; error: 19 Build 5: aarch64/2019/dec/04 pass: 8,788; fail: 505; error: 17 Build 6: aarch64/2019/dec/07 pass: 8,819; fail: 524; error: 17 Build 7: aarch64/2019/dec/09 pass: 8,820; fail: 519; error: 21 Build 8: aarch64/2019/dec/11 pass: 8,818; fail: 520; error: 18 Build 9: aarch64/2019/dec/13 pass: 8,811; fail: 530; error: 17 Build 10: aarch64/2019/dec/16 pass: 8,813; fail: 529; error: 17 Build 11: aarch64/2019/dec/18 pass: 8,827; fail: 520; error: 16 Build 12: aarch64/2019/dec/20 pass: 8,818; fail: 528; error: 20 Build 13: aarch64/2019/dec/23 pass: 8,823; fail: 524; error: 20 Build 14: aarch64/2019/dec/25 pass: 8,819; fail: 530; error: 18 4 fatal errors were detected; please follow the link above for more detail. ------------------------------------------------------------------------------- release/langtools ------------------------------------------------------------------------------- Build 0: aarch64/2019/nov/22 pass: 3,981 Build 1: aarch64/2019/nov/25 pass: 3,983 Build 2: aarch64/2019/nov/27 pass: 4,006 Build 3: aarch64/2019/nov/29 pass: 4,006 Build 4: aarch64/2019/dec/02 pass: 4,002; fail: 5; error: 1 Build 5: aarch64/2019/dec/04 pass: 4,008 Build 6: aarch64/2019/dec/07 pass: 4,019 Build 7: aarch64/2019/dec/09 pass: 4,019 Build 8: aarch64/2019/dec/11 pass: 4,021 Build 9: aarch64/2019/dec/13 pass: 4,029 Build 10: aarch64/2019/dec/16 pass: 4,030 Build 11: aarch64/2019/dec/18 pass: 4,030 Build 12: aarch64/2019/dec/20 pass: 4,030 Build 13: aarch64/2019/dec/23 pass: 4,030 Build 14: aarch64/2019/dec/25 pass: 4,030 ------------------------------------------------------------------------------- server-release/hotspot ------------------------------------------------------------------------------- Build 0: aarch64/2018/oct/15 pass: 5,787; fail: 18; not run: 90 ------------------------------------------------------------------------------- server-release/jdk ------------------------------------------------------------------------------- Build 0: aarch64/2018/oct/15 pass: 8,476; fail: 686; error: 27 ------------------------------------------------------------------------------- server-release/langtools ------------------------------------------------------------------------------- Build 0: aarch64/2018/oct/15 pass: 3,970; fail: 5 Previous results can be found here: http://openjdk.linaro.org/jdkX/openjdk-jtreg-nightly-tests/index.html SPECjbb2015 composite regression test completed =============================================== This test measures the relative performance of the server compiler running the SPECjbb2015 composite tests and compares the performance against the baseline performance of the server compiler taken on 2016-11-21. In accordance with [1], the SPECjbb2015 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): 8.04x Relative performance: Server critical-jOPS (nc): 12.50x Details of the test setup and historical results may be found here: http://openjdk.linaro.org/jdkX/SPECjbb2015-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 server compiler on 2014-04-01. Relative performance: Zero: 1.0, Server: 210.67 Server 210.67 / Server 2014-04-01 (71.00): 2.97x Details of the test setup and historical results may be found here: http://openjdk.linaro.org/jdkX/hadoop-terasort-benchmark-results/ This is a summary of the jcstress test results ============================================== The build and test results are cycled every 15 days. 2019-11-23 pass rate: 10490/10490, results: http://openjdk.linaro.org/jdkX/jcstress-nightly-runs/2019/326/results/ 2019-11-26 pass rate: 10490/10490, results: http://openjdk.linaro.org/jdkX/jcstress-nightly-runs/2019/329/results/ 2019-12-03 pass rate: 10490/10490, results: http://openjdk.linaro.org/jdkX/jcstress-nightly-runs/2019/331/results/ 2019-12-04 pass rate: 10490/10490, results: http://openjdk.linaro.org/jdkX/jcstress-nightly-runs/2019/333/results/ 2019-12-05 pass rate: 10490/10490, results: http://openjdk.linaro.org/jdkX/jcstress-nightly-runs/2019/336/results/ 2019-12-07 pass rate: 10490/10490, results: http://openjdk.linaro.org/jdkX/jcstress-nightly-runs/2019/338/results/ 2019-12-08 pass rate: 10490/10490, results: http://openjdk.linaro.org/jdkX/jcstress-nightly-runs/2019/341/results/ 2019-12-10 pass rate: 10490/10490, results: http://openjdk.linaro.org/jdkX/jcstress-nightly-runs/2019/343/results/ 2019-12-12 pass rate: 10490/10490, results: http://openjdk.linaro.org/jdkX/jcstress-nightly-runs/2019/345/results/ 2019-12-14 pass rate: 10490/10490, results: http://openjdk.linaro.org/jdkX/jcstress-nightly-runs/2019/347/results/ 2019-12-17 pass rate: 10490/10490, results: http://openjdk.linaro.org/jdkX/jcstress-nightly-runs/2019/350/results/ 2019-12-19 pass rate: 10490/10490, results: http://openjdk.linaro.org/jdkX/jcstress-nightly-runs/2019/352/results/ 2019-12-21 pass rate: 10490/10490, results: http://openjdk.linaro.org/jdkX/jcstress-nightly-runs/2019/354/results/ 2019-12-24 pass rate: 10490/10490, results: http://openjdk.linaro.org/jdkX/jcstress-nightly-runs/2019/357/results/ 2019-12-26 pass rate: 10490/10490, results: http://openjdk.linaro.org/jdkX/jcstress-nightly-runs/2019/359/results/ For detailed information on the test output please refer to: http://openjdk.linaro.org/jdkX/jcstress-nightly-runs/ From robbin.ehn at oracle.com Thu Dec 19 11:37:47 2019 From: robbin.ehn at oracle.com (Robbin Ehn) Date: Thu, 19 Dec 2019 11:37:47 -0000 Subject: [aarch64-port-dev ] Question: JNI critical native support is not fully implemented for AArch64? In-Reply-To: <19c47e46-c0b3-ef63-879b-b736c210e1ad@redhat.com> References: <19c47e46-c0b3-ef63-879b-b736c210e1ad@redhat.com> Message-ID: <0d784d57-ad2f-4145-bdfe-8933b2045ce5@oracle.com> Hi, The lazy part of this, not taking the GC locker, instead letting the VM thread do it while safepointing causes some troubles. The GC lock can be locked _after_ the safepoint have started, GC must thus abort the safepoint. It relies on the _suspend_flags which we are trying to remove (in favor of handshakes), so we need to do something about it. If this is something the vm needs I would rather see it in Panama with a different solution. I need to test the performance difference, but if it's small I would suggest removing it completely. So before anyone starts implementing/spreading the use of this can we have some time to evaluate? Thanks, Robbin On 12/19/19 11:10 AM, Andrew Haley wrote: > On 12/19/19 7:42 AM, Pengfei Li wrote: >> While I also see someone saying that this feature is designed for internal use only and there is no public specification for it[2]. And I don't know if there is any real workload currently using it. So could anyone tell me if "Critical Natives" is a sort of "public feature" of OpenJDK? And is there much value to complement the implementation for AArch64? > > For anything to be fixed we'd need to write some code that uses critical natives, > at least to test it. It'd be interesting to see what this could be used for. It > might be useful. >