November 2019 - aarch64-port-dev

RFR(M): 8233743: AArch64: Make r27 conditionally allocatable
by Pengfei Li (Arm Technology China) 23 Dec '19

23 Dec '19

Hi, JBS: https://bugs.openjdk.java.net/browse/JDK-8233743 Webrev: http://cr.openjdk.java.net/~pli/rfr/8233743/webrev.00/ This is a follow-up patch of JDK-8217909[1] to make the AArch64 register r27 allocatable when CompressedOops and CompressedClassPointers are both turned off. Below changes have been made: - Massage the RegMask(s) in reg_mask_init() at C2 initialization and remove r27 from some of the masks conditionally to make it allocatable. - Also make r29 conditionally reserved in this similar way. - Make r29 allocatable for pointers as well as integers. - Replace an rheapbase use to rscratch1 in AArch64 ZGC. - Revert JDK-8231754[2] which makes r27 always reserved in JVMCI. This patch aligns with the implementation in [1] which makes the x86_64 r12 register allocatable. Please let me know if I have missed anything for AArch64. Tests: Full jtreg with default options and extra options "-XX:-UseCompressedOops -XX:+PreserveFramePointer". No new failure is found. [1] https://hg.openjdk.java.net/jdk/jdk/rev/48b50573dee4 [2] https://hg.openjdk.java.net/jdk/jdk/rev/d068b1e534de -- Thanks, Pengfei

7 32

RFR (trivial): 8234228: AArch64: Clean up redundant temp vars in generate_compare_long_string_different_encoding
by Patrick Zhang OS 19 Dec '19

19 Dec '19

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/com… [2] http://cr.openjdk.java.net/~shade/density/string-density-bench.jar Regards Patrick

2 5

Re: [aarch64-port-dev ] RFR: 8229351: AArch64: Make the stub threshold of string_compare intrinsic tunable
by Patrick Zhang OS 19 Dec '19

19 Dec '19

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] 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 <aarch64-port-dev-bounces(a)openjdk.java.net> On Behalf Of Patrick Zhang OS Sent: Friday, November 15, 2019 4:05 PM To: Andrew Haley <aph(a)redhat.com>; Andrew Dinn <adinn(a)redhat.com> Cc: aarch64-port-dev(a)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 <aarch64-port-dev-bounces(a)openjdk.java.net> On Behalf Of Patrick Zhang OS Sent: Thursday, November 14, 2019 7:14 PM To: Andrew Haley <aph(a)redhat.com>; aarch64-port-dev(a)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/aarch6… 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/aarch6…) 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/aarch6…) I can prepare a new patch with the updates to tests, and plot the timings soon latter. Regards Patrick -----Original Message----- From: Andrew Haley <aph(a)redhat.com> Sent: Thursday, November 14, 2019 6:33 PM To: Patrick Zhang OS <patrick(a)os.amperecomputing.com>; aarch64-port-dev(a)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://www.redhat.com> https://keybase.io/andrewhaley EAC8 43EB D3EF DB98 CC77 2FAD A5CD 6035 332F A671

2 4

[RFR] [8u] 8u242-b01 Upstream Sync
by Andrew John Hughes 11 Dec '19

11 Dec '19

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.change… http://cr.openjdk.java.net/~andrew/shenandoah-8/u242-b01/jaxp/merge.changes… http://cr.openjdk.java.net/~andrew/shenandoah-8/u242-b01/jaxws/merge.change… 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.chan… http://cr.openjdk.java.net/~andrew/shenandoah-8/u242-b01/langtools/merge.ch… http://cr.openjdk.java.net/~andrew/shenandoah-8/u242-b01/nashorn/merge.chan… http://cr.openjdk.java.net/~andrew/shenandoah-8/u242-b01/root/merge.changes… 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/050fe… 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

3 2

RFR: 8233948: AArch64: Incorrect mapping between OptoReg and VMReg for high 64 bits of Vector Register
by Joshua Zhu (Arm Technology China) 06 Dec '19

06 Dec '19

Hi, Please review the following patch: JBS: https://bugs.openjdk.java.net/browse/JDK-8233948 Webrev: http://cr.openjdk.java.net/~jzhu/8233948/webrev.00/ In register definition of aarch64.ad, each vector register is defined as 4 slots with its calling convention, ideal type, ... and its VMReg value. These VMReg values in reg_def are used by ADLC to generate mapping between OptoReg and VMReg: opto2vm[]. But VMReg is treated as 2 slots inconsistently for vector register [1]. This causes incorrect mapping between VMReg and OptoReg for high 64 bits of vector register. If we write the following codes which will access high 64 bits of vector register in a way like vector_calling_convention in panama branch [2]: VMReg vmreg = v0->as_VMReg(); VMRegPair p; p.set_pair(vmreg->next(3), vmreg); And convert the VMRegPair into OptoReg [3]: Regmask rm; OptoReg::Name reg_fst = OptoReg::as_OptoReg(p.first()); OptoReg::Name reg_snd = OptoReg::as_OptoReg(p.second()); tty->print("fst=%d snd=%d\n", reg_fst, reg_snd); for (OptoReg::Name r = reg_fst; r <= reg_snd; r++) { rm->Insert(r); } In this case, for V0's VMRegPair, first VMReg's value is 64 and second one is 67. After conversion by as_OptoReg(), first OptoReg becomes 124 and second one becomes 129. Then totally 6 bits of RegMask are set incorrectly, should be 4 bits (represent 4 slots/halves). VMReg, opto2vm[] and vm2opto[] are dumped by [4] as below for reference: http://cr.openjdk.java.net/~jzhu/8233948/RegDump_before_change.log opto2vm[] has the following items: OptoReg: 126, VMReg: 66 OptoReg: 127, VMReg: 67 OptoReg: 128, VMReg: 66 OptoReg: 129, VMReg: 67 OptoReg pair [126, 127] and [128, 129] are both mapped to the same VMReg Pair [66, 67]. vm2opto are then generated by traverse of opto2vm [5]. VMReg: 66, OptoReg: 128 VMReg: 67, OptoReg: 129 This caused incorrect RegMask generated in above case. However for floating-point register, bottom 64 bits of NEON vector register overlaps with floating-point register. Their VMReg and corresponding mapping is still consistent, therefore this issue is not exposed. But I think we should still fix it to make the codes clean and avoid potential issue in future. After fix, the dump is: http://cr.openjdk.java.net/~jzhu/8233948/RegDump_after_change.log [1] https://hg.openjdk.java.net/jdk/jdk/file/d595f1faace2/src/hotspot/cpu/aarch… [2] https://hg.openjdk.java.net/panama/dev/file/43bc39c09590/src/hotspot/cpu/x8… [3] https://hg.openjdk.java.net/panama/dev/file/43bc39c09590/src/hotspot/share/… [4] http://cr.openjdk.java.net/~jzhu/8233948/dump.patch [5] https://hg.openjdk.java.net/jdk/jdk/file/d595f1faace2/src/hotspot/share/opt… Best Regards, Joshua

3 8

RFR(S): 8234791: Fix Client VM build for x86_64 and AArch64
by Pengfei Li (Arm Technology China) 04 Dec '19

04 Dec '19

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/runt… [3] http://hg.openjdk.java.net/jdk/jdk/file/981a55672786/src/hotspot/share/runt… [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

5 8

Re: [aarch64-port-dev ] Question about ISB usage in the aarch64 port
by Yangfei (Felix) 29 Nov '19

29 Nov '19

Any comments on that? I have posted some of the hs_err_log files here: http://cr.openjdk.java.net/~fyang/sigill-crashes.tar.bz2 Thanks, Felix From: Yangfei (Felix) Sent: Tuesday, November 12, 2019 3:37 PM To: aarch64-port-dev(a)openjdk.java.net Subject: Question about ISB usage in the aarch64 port Hi, I am witnessing some SIGILL jvm crashes on my aarch64 platform. I looked at the ISB usage, especially this one: https://mail.openjdk.java.net/pipermail/aarch64-port-dev/2014-September/001… One of changes is adding one ISB after the native call returns: 1100 static void rt_call(MacroAssembler* masm, address dest, int gpargs, int fpargs, int type) { 1101 CodeBlob *cb = CodeCache::find_blob(dest); 1102 if (cb) { 1103 __ far_call(RuntimeAddress(dest)); 1104 } else { 1105 assert((unsigned)gpargs < 256, "eek!"); 1106 assert((unsigned)fpargs < 32, "eek!"); 1107 __ lea(rscratch1, RuntimeAddress(dest)); 1108 __ blr(rscratch1); 1109 __ maybe_isb(); < ======== 1110 } 1111 } The rt_call function is used in generate_native_wrapper to make the JNI call. As I didn’t see the barrier for the ppc or arm port. I would like to know more details here. Does anyone still remember? Also the ISB is planted only in the else block. I assume this is also necessary for the if block. Correct? Thanks for your help, Felix

3 11

Re: [aarch64-port-dev ] RFR(XS): 8233466: aarch64: remove unnecessary load of mdo when profiling return and parameters type
by Yangfei (Felix) 29 Nov '19

29 Nov '19

Ping… Any comments? Thanks, Felix From: Yangfei (Felix) Sent: Thursday, November 7, 2019 9:17 AM To: hotspot-runtime-dev(a)openjdk.java.net; aarch64-port-dev(a)openjdk.java.net Subject: RFR(XS): 8233466: aarch64: remove unnecessary load of mdo when profiling return and parameters type Hi, Please review the following patch: Bug: https://bugs.openjdk.java.net/browse/JDK-8233466 Webrev: http://cr.openjdk.java.net/~fyang/8233466/webrev.00/ When profiling return and parameters type from the interpreter on aarch64 platform, 'mdp' is loaded by test_method_data_pointer which is called by profile_return_type & profile_parameters_type. It's not necessary to load mdo before calling __ profile_return_type or __ profile_parameters_type. Passed tier1-3 testing. Thanks, Felix

2 2

RFR(S) 8234891: AArch64: Fix build failure after JDK-8234387
by Boris Ulasevich 28 Nov '19

28 Nov '19

Hi, Please review the fix in aarch64.ad to address the build issue "Ideal node missing: CmpOp" raised after recent change in C2. The intuitive operand name case correction CmpOp->cmpOp fixes the build, but leads to unworkable jvm. Removing the match rule works good and jdk/hotspot tests are Ok. http://bugs.openjdk.java.net/browse/JDK-8234891 http://cr.openjdk.java.net/~bulasevich/8234891/webrev.00 ARM32 build fails too. I will fix the problem in arm32.ad file separately. thanks, Boris

4 4

runtime/memory/ReadFromNoaccessArea.java crashes on aarch64
by Baesken, Matthias 26 Nov '19

26 Nov '19

Hello, are you aware that the jtreg hotspot test runtime/memory/ReadFromNoaccessArea.java crashes on aarch64 for some days ? We notice the crash since 15. November . The stderr output is like this : stdout: [# # A fatal error has been detected by the Java Runtime Environment: # # Internal Error (vtableStubs.cpp:197), pid=6213, tid=6217 # guarantee(masm->pc() <= s->code_end()) failed: itable #2: overflowed buffer, estimated len: 176, actual len: 180, overrun: 4 # # JRE version: OpenJDK Runtime Environment (14.0.0.1) (build 14.0.0.1-internal+0-adhoc.openjdk.jdk) # Java VM: OpenJDK 64-Bit Server VM (14.0.0.1-internal+0-adhoc.openjdk.jdk, mixed mode, sharing, tiered, compressed oops, g1 gc, linux-aarch64) # Problematic frame: # V [libjvm.so+0xdcd534] VtableStubs::bookkeeping(MacroAssembler*, outputStream*, VtableStub*, unsigned char*, unsigned char*, bool, int, int, int)+0x114 # # CreateCoredumpOnCrash turned off, no core file dumped # # An error report file with more information is saved as: # /mytestdir/jtreg_hotspot_tier1_work/JTwork/runtime/memory/ReadFromNoaccessArea/hs_err_pid6213.log # # If you would like to submit a bug report, please visit: # https://bugreport.java.com/bugreport/crash.jsp # ]; stderr: [] exitValue = 1 java.lang.RuntimeException: 'SIGSEGV' missing from stdout/stderr at jdk.test.lib.process.OutputAnalyzer.shouldContain(OutputAnalyzer.java:187) at ReadFromNoaccessArea.main(ReadFromNoaccessArea.java:74) at java.base/jdk.internal.reflect.NativeMethodAccessorImpl.invoke0(Native Method) at java.base/jdk.internal.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:62) at java.base/jdk.internal.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43) at java.base/java.lang.reflect.Method.invoke(Method.java:564) at com.sun.javatest.regtest.agent.MainWrapper$MainThread.run(MainWrapper.java:127) at java.base/java.lang.Thread.run(Thread.java:833) JavaTest Message: Test threw exception: java.lang.RuntimeException: 'SIGSEGV' missing from stdout/stderr JavaTest Message: shutting down test STATUS:Failed.`main' threw exception: java.lang.RuntimeException: 'SIGSEGV' missing from stdout/stderr Thread info from hs_err --------------- T H R E A D --------------- Current thread (0x0000ffffa4028800): JavaThread "main" [_thread_in_vm, id=6217, stack(0x0000ffffa9f3b000,0x0000ffffaa13b000)] Stack: [0x0000ffffa9f3b000,0x0000ffffaa13b000], sp=0x0000ffffaa137f40, free space=2035k Native frames: (J=compiled Java code, A=aot compiled Java code, j=interpreted, Vv=VM code, C=native code) V [libjvm.so+0xdcd534] VtableStubs::bookkeeping(MacroAssembler*, outputStream*, VtableStub*, unsigned char*, unsigned char*, bool, int, int, int)+0x114 V [libjvm.so+0xdce1fc] VtableStubs::create_itable_stub(int)+0x584 V [libjvm.so+0xdccbd0] VtableStubs::find_stub(bool, int)+0x1f0 V [libjvm.so+0x4e165c] CompiledIC::set_to_megamorphic(CallInfo*, Bytecodes::Code, bool&, Thread*)+0x74 V [libjvm.so+0xb62358] SharedRuntime::handle_ic_miss_helper_internal(Handle, CompiledMethod*, frame const&, methodHandle, Bytecodes::Code, CallInfo&, bool&, Thread*)+0x1e0 V [libjvm.so+0xb63144] SharedRuntime::handle_ic_miss_helper(JavaThread*, Thread*)+0x6c4 V [libjvm.so+0xb63380] SharedRuntime::handle_wrong_method_ic_miss(JavaThread*)+0x38 v ~RuntimeStub::ic_miss_stub j jdk.internal.module.ModuleBootstrap.boot()Ljava/lang/ModuleLayer;+1323 java.base(a)14.0.0.1-internal j java.lang.System.initPhase2(ZZ)I+0 java.base(a)14.0.0.1-internal v ~StubRoutines::call_stub V [libjvm.so+0x712b60] JavaCalls::call_helper(JavaValue*, methodHandle const&, JavaCallArguments*, Thread*)+0x368 V [libjvm.so+0x711460] JavaCalls::call_static(JavaValue*, Klass*, Symbol*, Symbol*, JavaCallArguments*, Thread*)+0xf8 V [libjvm.so+0xd5a2dc] Threads::create_vm(JavaVMInitArgs*, bool*)+0x8f4 V [libjvm.so+0x7a23b0] JNI_CreateJavaVM+0x78 C [libjli.so+0x48d0] JavaMain+0x70 C [libjli.so+0x885c] ThreadJavaMain+0xc C [libpthread.so.0+0x7060] start_thread+0xb0 Java frames: (J=compiled Java code, j=interpreted, Vv=VM code) v ~RuntimeStub::ic_miss_stub J 41 c1 jdk.internal.module.ModuleBootstrap$2.hasNext()Z java.base(a)14.0.0.1-internal (30 bytes) @ 0x0000ffff8cbf12e0 [0x0000ffff8cbf1080+0x0000000000000260] j java.lang.Module.implAddOpensToAllUnnamed(Ljava/util/Iterator;)V+47 java.base(a)14.0.0.1-internal j java.lang.System$2.addOpensToAllUnnamed(Ljava/lang/Module;Ljava/util/Iterator;)V+2 java.base(a)14.0.0.1-internal j jdk.internal.module.ModuleBootstrap.addIllegalAccess(Ljava/lang/module/ModuleFinder;Ljava/util/Map;Ljava/util/Map;Ljava/lang/ModuleLayer;Z)V+573 java.base(a)14.0.0.1-internal j jdk.internal.module.ModuleBootstrap.boot()Ljava/lang/ModuleLayer;+1323 java.base(a)14.0.0.1-internal j java.lang.System.initPhase2(ZZ)I+0 java.base(a)14.0.0.1-internal v ~StubRoutines::call_stub Best regards, Matthias

2 1