- aarch64-port-dev - openjdk.org

Re: [aarch64-port-dev ] AArch64: Incorrect matching rule leading to improper oop instruction encoding
by wangyadong (E) 09 Jul '25

09 Jul '25

Hi, Maybe we can just add an extra predicate condition to check whether the ConP node is TypeOopPtr or TypeRawPtr? diff --git a/hotspot/src/cpu/aarch64/vm/aarch64.ad b/hotspot/src/cpu/aarch64/vm/aarch64.ad index d73d5d457..347c29263 100644 --- a/hotspot/src/cpu/aarch64/vm/aarch64.ad +++ b/hotspot/src/cpu/aarch64/vm/aarch64.ad @@ -4315,8 +4315,8 @@ operand immPollPage() operand immByteMapBase() %{ // Get base of card map - predicate((jbyte*)n->get_ptr() == - ((CardTableModRefBS*)(Universe::heap()->barrier_set()))->byte_map_base); + predicate(n->get_ptr_type()->isa_rawptr() != NULL && + (jbyte*)n->get_ptr() == ((CardTableModRefBS*)(Universe::heap()->barrier_set()))->byte_map_base); match(ConP); op_cost(0); By the way, the polling page may conflict with byte_map_base, but it's safe now because they are both raw pointers and has same instruction sequence (adrp) with different relocTypes. Yadong From: wangyadong (E) Sent: Monday, July 7, 2025 7:47 PM To: 'aleksey(a)shipilev.net' <aleksey(a)shipilev.net>; 'yangfei(a)iscas.ac.cn' <yangfei(a)iscas.ac.cn> Subject: RE: AArch64: Incorrect matching rule leading to improper oop instruction encoding Hi, guys, I sent a suspected bug for AArch64 port for incorrect using byte_map_base in aarch64.ad. Could you please help me see if there is a suitable solution? You can reproduce the bug using the test case and a jvm patch intentionally allocating JNIHandleBlock to the byte_map_base address: https://github.com/feilongjiang/jdk8u-dev/commit/839f519a8b8355ab5559962c79… From: wangyadong (E) Sent: Sunday, July 6, 2025 7:46 PM To: 'aarch64-port-dev(a)openjdk.org' <aarch64-port-dev(a)openjdk.org<mailto:aarch64-port-dev@openjdk.org>> Subject: AArch64: Incorrect matching rule leading to improper oop instruction encoding Hi, guys, We have found a suspected C2 bug of Aarch64 port, randomly crashed in the arm64 server, and existed since day one from the initial commit and on all Java 8+ versions. C2 uses JNI handles as placeholders to encoding constant oops, and one of some handle maybe locate at the address of byte_map_base, which is not memory reserved by CardTableModRefBS byte_map. // The assember store_check code will do an unsigned shift of the oop, // then add it to byte_map_base, i.e. // // _byte_map = byte_map_base + (uintptr_t(low_bound) >> card_shift) _byte_map = (jbyte*) heap_rs.base(); byte_map_base = _byte_map - (uintptr_t(low_bound) >> card_shift); C2 will incorrectly match ConP of oop to ConP of byte_map_base in aarch64.ad. // Card Table Byte Map Base operand immByteMapBase() %{ // Get base of card map predicate((jbyte*)n->get_ptr() == ((CardTableModRefBS*)(Universe::heap()->barrier_set()))->byte_map_base); match(ConP); op_cost(0); format %{ %} interface(CONST_INTER); %} // Load Byte Map Base Constant instruct loadByteMapBase(iRegPNoSp dst, immByteMapBase con) %{ match(Set dst con); ins_cost(INSN_COST); format %{ "adr $dst, $con\t# Byte Map Base" %} ins_encode(aarch64_enc_mov_byte_map_base(dst, con)); ins_pipe(ialu_imm); %} A typical backtrace as below: #0 0x0000ffff280866e0 in raise () from /lib64/libc.so.6 #1 0x0000ffff28087a8c in abort () from /lib64/libc.so.6 #2 0x0000ffff27af1e7c in os::abort (dump_core=true, siginfo=<optimized out>, context=<optimized out>) at /usr1/jenkins/BiShengJDK/open_source/openjdk/openjdk/hotspot/src/os/linux/vm/os_linux.cpp:1601 #3 0x0000ffff27cd48a0 in VMError::report_and_die (this=this@entry=0xffff270f6c58) at /usr1/jenkins/BiShengJDK/open_source/openjdk/openjdk/hotspot/src/share/vm/utilities/vmError.cpp:1159 #4 0x0000ffff27aff4dc in JVM_handle_linux_signal (sig=11, info=info@entry=0xffff270f6d80, ucVoid=0xffff270f6e00, abort_if_unrecognized=abort_if_unrecognized@entry=1) at /usr1/jenkins/BiShengJDK/open_source/openjdk/openjdk/hotspot/src/os_cpu/linux_aarch64/vm/os_linux_aarch64.cpp:410 #5 0x0000ffff27aee3b0 in signalHandler (sig=<optimized out>, info=0xffff270f6d80, uc=<optimized out>) at /usr1/jenkins/BiShengJDK/open_source/openjdk/openjdk/hotspot/src/os/linux/vm/os_linux.cpp:4839 #6 <signal handler called> #7 Klass::layout_helper (this=0x8b56b87d8) at /usr1/jenkins/BiShengJDK/open_source/openjdk/openjdk/hotspot/src/share/vm/oops/klass.hpp:577 #8 Klass::oop_is_instance (this=0x8b56b87d8) at /usr1/jenkins/BiShengJDK/open_source/openjdk/openjdk/hotspot/src/share/vm/oops/klass.hpp:577 #9 oopDesc::is_instance (this=<optimized out>) at /usr1/jenkins/BiShengJDK/open_source/openjdk/openjdk/hotspot/src/share/vm/oops/oop.inline.hpp:186 #10 ServiceUtil::visible_oop (o=<optimized out>) at /usr1/jenkins/BiShengJDK/open_source/openjdk/openjdk/hotspot/src/share/vm/services/serviceUtil.hpp:47 #11 JavaThreadBlockedOnMonitorEnterState::JavaThreadBlockedOnMonitorEnterState (obj_m=0xffff180114d8, java_thread=0xffff20029000, this=<synthetic pointer>) at /usr1/jenkins/BiShengJDK/open_source/openjdk/openjdk/hotspot/src/share/vm/services/threadService.hpp:552 #12 ObjectMonitor::enter (this=0xffff180114d8, __the_thread__=__the_thread__@entry=0xffff20029000) at /usr1/jenkins/BiShengJDK/open_source/openjdk/openjdk/hotspot/src/share/vm/runtime/objectMonitor.cpp:390 #13 0x0000ffff27c271dc in ObjectSynchronizer::slow_enter (__the_thread__=0xffff20029000, lock=0xffff270f8130, obj=...) at /usr1/jenkins/BiShengJDK/open_source/openjdk/openjdk/hotspot/src/share/vm/runtime/handles.hpp:79 #14 ObjectSynchronizer::fast_enter (obj=..., lock=lock@entry=0xffff270f8130, attempt_rebias=attempt_rebias@entry=true, __the_thread__=__the_thread__@entry=0xffff20029000) at /usr1/jenkins/BiShengJDK/open_source/openjdk/openjdk/hotspot/src/share/vm/runtime/synchronizer.cpp:183 #15 0x0000ffff27bb10b0 in SharedRuntime::complete_monitor_locking_C (_obj=0xffff21730000, lock=0xffff270f8130, thread=0xffff20029000) at /usr1/jenkins/BiShengJDK/open_source/openjdk/openjdk/hotspot/src/share/vm/runtime/sharedRuntime.cpp:1879 #16 0x0000ffff256ffff8 in ?? () #17 0x0000ffff277a0414 in InstanceKlass::register_finalizer (i=<optimized out>, __the_thread__=0xfffeebc09d20) at /usr1/jenkins/BiShengJDK/open_source/openjdk/openjdk/hotspot/src/share/vm/utilities/growableArray.hpp:261 #18 0x0000ffff277a0414 in InstanceKlass::register_finalizer (i=<optimized out>, __the_thread__=0xffff20029000) at /usr1/jenkins/BiShengJDK/open_source/openjdk/openjdk/hotspot/src/share/vm/utilities/growableArray.hpp:261 #19 0x0000ffff270f8390 in ?? () #20 0x00000007ad622658 in ?? () Passing byte_map_base instead of oop to complete_monitor_locking_C: #15 0x0000ffff27bb10b0 in SharedRuntime::complete_monitor_locking_C (_obj=0xffff21730000, lock=0xffff270f8130, thread=0xffff20029000) at /usr1/jenkins/BiShengJDK/open_source/openjdk/openjdk/hotspot/src/share/vm/runtime/sharedRuntime.cpp:1879 Called by complete_monitor_lock_Java: 0xffff256fffc0: nop 0xffff256fffc4: sub sp, sp, #0x10 0xffff256fffc8: stp x29, x30, [sp] 0xffff256fffcc: mov x9, sp 0xffff256fffd0: str x9, [x28, #592] 0xffff256fffd4: mov x0, x1 0xffff256fffd8: mov x1, x2 0xffff256fffdc: mov x2, x28 0xffff256fffe0: adr x9, 0xffff256ffff8 0xffff256fffe4: mov x8, #0xff0 // #4080 0xffff256fffe8: movk x8, #0x27bb, lsl #16 0xffff256fffec: movk x8, #0xffff, lsl #32 0xffff256ffff0: stp xzr, x9, [sp, #-16]! 0xffff256ffff4: blr x8 0xffff256ffff8: add sp, sp, #0x10 0xffff256ffffc: str xzr, [x28, #592] 0xffff25700000: str xzr, [x28, #600] 0xffff25700004: ldr x10, [x28, #8] 0xffff25700008: cbnz x10, 0xffff25700018 0xffff2570000c: ldp x29, x30, [sp] 0xffff25700010: add sp, sp, #0x10 0xffff25700014: ret 0xffff25700018: adrp x10, 0xffff25580000 0xffff2570001c: add x10, x10, #0x340 0xffff25700020: mov x12, xzr 0xffff25700024: ldp x29, x30, [sp] 0xffff25700028: add sp, sp, #0x10 0xffff2570002c: br x10 Called by J 1821 C2 java.lang.ref.Finalizer.register(Ljava/lang/Object;)V (10 bytes) @ 0x0000ffff25caf0bc [0x0000ffff25caee80+0x23c] 0xffff25caf0b4: adrp x1, 0xffff21730000 0xffff25caf0b8: bl 0xffff256fffc0 Which encoding byte_map_base instead of the specific oop and passing it to complete_monitor_lock_Java. So the entire story is that the predicate rule of immByteMapBase caused an incorrect ConP match when a corresponding JNIHandleBlock with an oop was allocated to the address of byte_map_base by malloc. I have a simple fix that just remove the specialized match rule for immByteMapBase below, and crashes disappeared. diff --git a/hotspot/src/cpu/aarch64/vm/aarch64.ad b/hotspot/src/cpu/aarch64/vm/aarch64.ad index d73d5d457..5305467c1 100644 --- a/hotspot/src/cpu/aarch64/vm/aarch64.ad +++ b/hotspot/src/cpu/aarch64/vm/aarch64.ad @@ -3054,11 +3054,6 @@ encode %{ assert(off == 0, "assumed offset == 0"); %} - enc_class aarch64_enc_mov_byte_map_base(iRegP dst, immByteMapBase src) %{ - MacroAssembler _masm(&cbuf); - __ load_byte_map_base($dst$$Register); - %} - enc_class aarch64_enc_mov_n(iRegN dst, immN src) %{ MacroAssembler _masm(&cbuf); Register dst_reg = as_Register($dst$$reg); @@ -4311,19 +4306,6 @@ operand immPollPage() interface(CONST_INTER); %} -// Card Table Byte Map Base -operand immByteMapBase() -%{ - // Get base of card map - predicate((jbyte*)n->get_ptr() == - ((CardTableModRefBS*)(Universe::heap()->barrier_set()))->byte_map_base); - match(ConP); - - op_cost(0); - format %{ %} - interface(CONST_INTER); -%} - // Pointer Immediate Minus One // this is used when we want to write the current PC to the thread anchor operand immP_M1() @@ -6772,20 +6754,6 @@ instruct loadConPollPage(iRegPNoSp dst, immPollPage con) ins_pipe(ialu_imm); %} -// Load Byte Map Base Constant - -instruct loadByteMapBase(iRegPNoSp dst, immByteMapBase con) -%{ - match(Set dst con); - - ins_cost(INSN_COST); - format %{ "adr $dst, $con\t# Byte Map Base" %} - - ins_encode(aarch64_enc_mov_byte_map_base(dst, con)); - - ins_pipe(ialu_imm); -%} - // Load Narrow Pointer Constant instruct loadConN(iRegNNoSp dst, immN con) Does anyone have any suggestions on this? Yadong

1 0

AArch64: Incorrect matching rule leading to improper oop instruction encoding
by wangyadong (E) 06 Jul '25

06 Jul '25

Hi, guys, We have found a suspected C2 bug of Aarch64 port, randomly crashed in the arm64 server, and existed since day one from the initial commit and on all Java 8+ versions. C2 uses JNI handles as placeholders to encoding constant oops, and one of some handle maybe locate at the address of byte_map_base, which is not memory reserved by CardTableModRefBS byte_map. // The assember store_check code will do an unsigned shift of the oop, // then add it to byte_map_base, i.e. // // _byte_map = byte_map_base + (uintptr_t(low_bound) >> card_shift) _byte_map = (jbyte*) heap_rs.base(); byte_map_base = _byte_map - (uintptr_t(low_bound) >> card_shift); C2 will incorrectly match ConP of oop to ConP of byte_map_base in aarch64.ad. // Card Table Byte Map Base operand immByteMapBase() %{ // Get base of card map predicate((jbyte*)n->get_ptr() == ((CardTableModRefBS*)(Universe::heap()->barrier_set()))->byte_map_base); match(ConP); op_cost(0); format %{ %} interface(CONST_INTER); %} // Load Byte Map Base Constant instruct loadByteMapBase(iRegPNoSp dst, immByteMapBase con) %{ match(Set dst con); ins_cost(INSN_COST); format %{ "adr $dst, $con\t# Byte Map Base" %} ins_encode(aarch64_enc_mov_byte_map_base(dst, con)); ins_pipe(ialu_imm); %} A typical backtrace as below: #0 0x0000ffff280866e0 in raise () from /lib64/libc.so.6 #1 0x0000ffff28087a8c in abort () from /lib64/libc.so.6 #2 0x0000ffff27af1e7c in os::abort (dump_core=true, siginfo=<optimized out>, context=<optimized out>) at /usr1/jenkins/BiShengJDK/open_source/openjdk/openjdk/hotspot/src/os/linux/vm/os_linux.cpp:1601 #3 0x0000ffff27cd48a0 in VMError::report_and_die (this=this@entry=0xffff270f6c58) at /usr1/jenkins/BiShengJDK/open_source/openjdk/openjdk/hotspot/src/share/vm/utilities/vmError.cpp:1159 #4 0x0000ffff27aff4dc in JVM_handle_linux_signal (sig=11, info=info@entry=0xffff270f6d80, ucVoid=0xffff270f6e00, abort_if_unrecognized=abort_if_unrecognized@entry=1) at /usr1/jenkins/BiShengJDK/open_source/openjdk/openjdk/hotspot/src/os_cpu/linux_aarch64/vm/os_linux_aarch64.cpp:410 #5 0x0000ffff27aee3b0 in signalHandler (sig=<optimized out>, info=0xffff270f6d80, uc=<optimized out>) at /usr1/jenkins/BiShengJDK/open_source/openjdk/openjdk/hotspot/src/os/linux/vm/os_linux.cpp:4839 #6 <signal handler called> #7 Klass::layout_helper (this=0x8b56b87d8) at /usr1/jenkins/BiShengJDK/open_source/openjdk/openjdk/hotspot/src/share/vm/oops/klass.hpp:577 #8 Klass::oop_is_instance (this=0x8b56b87d8) at /usr1/jenkins/BiShengJDK/open_source/openjdk/openjdk/hotspot/src/share/vm/oops/klass.hpp:577 #9 oopDesc::is_instance (this=<optimized out>) at /usr1/jenkins/BiShengJDK/open_source/openjdk/openjdk/hotspot/src/share/vm/oops/oop.inline.hpp:186 #10 ServiceUtil::visible_oop (o=<optimized out>) at /usr1/jenkins/BiShengJDK/open_source/openjdk/openjdk/hotspot/src/share/vm/services/serviceUtil.hpp:47 #11 JavaThreadBlockedOnMonitorEnterState::JavaThreadBlockedOnMonitorEnterState (obj_m=0xffff180114d8, java_thread=0xffff20029000, this=<synthetic pointer>) at /usr1/jenkins/BiShengJDK/open_source/openjdk/openjdk/hotspot/src/share/vm/services/threadService.hpp:552 #12 ObjectMonitor::enter (this=0xffff180114d8, __the_thread__=__the_thread__@entry=0xffff20029000) at /usr1/jenkins/BiShengJDK/open_source/openjdk/openjdk/hotspot/src/share/vm/runtime/objectMonitor.cpp:390 #13 0x0000ffff27c271dc in ObjectSynchronizer::slow_enter (__the_thread__=0xffff20029000, lock=0xffff270f8130, obj=...) at /usr1/jenkins/BiShengJDK/open_source/openjdk/openjdk/hotspot/src/share/vm/runtime/handles.hpp:79 #14 ObjectSynchronizer::fast_enter (obj=..., lock=lock@entry=0xffff270f8130, attempt_rebias=attempt_rebias@entry=true, __the_thread__=__the_thread__@entry=0xffff20029000) at /usr1/jenkins/BiShengJDK/open_source/openjdk/openjdk/hotspot/src/share/vm/runtime/synchronizer.cpp:183 #15 0x0000ffff27bb10b0 in SharedRuntime::complete_monitor_locking_C (_obj=0xffff21730000, lock=0xffff270f8130, thread=0xffff20029000) at /usr1/jenkins/BiShengJDK/open_source/openjdk/openjdk/hotspot/src/share/vm/runtime/sharedRuntime.cpp:1879 #16 0x0000ffff256ffff8 in ?? () #17 0x0000ffff277a0414 in InstanceKlass::register_finalizer (i=<optimized out>, __the_thread__=0xfffeebc09d20) at /usr1/jenkins/BiShengJDK/open_source/openjdk/openjdk/hotspot/src/share/vm/utilities/growableArray.hpp:261 #18 0x0000ffff277a0414 in InstanceKlass::register_finalizer (i=<optimized out>, __the_thread__=0xffff20029000) at /usr1/jenkins/BiShengJDK/open_source/openjdk/openjdk/hotspot/src/share/vm/utilities/growableArray.hpp:261 #19 0x0000ffff270f8390 in ?? () #20 0x00000007ad622658 in ?? () Passing byte_map_base instead of oop to complete_monitor_locking_C: #15 0x0000ffff27bb10b0 in SharedRuntime::complete_monitor_locking_C (_obj=0xffff21730000, lock=0xffff270f8130, thread=0xffff20029000) at /usr1/jenkins/BiShengJDK/open_source/openjdk/openjdk/hotspot/src/share/vm/runtime/sharedRuntime.cpp:1879 Called by complete_monitor_lock_Java: 0xffff256fffc0: nop 0xffff256fffc4: sub sp, sp, #0x10 0xffff256fffc8: stp x29, x30, [sp] 0xffff256fffcc: mov x9, sp 0xffff256fffd0: str x9, [x28, #592] 0xffff256fffd4: mov x0, x1 0xffff256fffd8: mov x1, x2 0xffff256fffdc: mov x2, x28 0xffff256fffe0: adr x9, 0xffff256ffff8 0xffff256fffe4: mov x8, #0xff0 // #4080 0xffff256fffe8: movk x8, #0x27bb, lsl #16 0xffff256fffec: movk x8, #0xffff, lsl #32 0xffff256ffff0: stp xzr, x9, [sp, #-16]! 0xffff256ffff4: blr x8 0xffff256ffff8: add sp, sp, #0x10 0xffff256ffffc: str xzr, [x28, #592] 0xffff25700000: str xzr, [x28, #600] 0xffff25700004: ldr x10, [x28, #8] 0xffff25700008: cbnz x10, 0xffff25700018 0xffff2570000c: ldp x29, x30, [sp] 0xffff25700010: add sp, sp, #0x10 0xffff25700014: ret 0xffff25700018: adrp x10, 0xffff25580000 0xffff2570001c: add x10, x10, #0x340 0xffff25700020: mov x12, xzr 0xffff25700024: ldp x29, x30, [sp] 0xffff25700028: add sp, sp, #0x10 0xffff2570002c: br x10 Called by J 1821 C2 java.lang.ref.Finalizer.register(Ljava/lang/Object;)V (10 bytes) @ 0x0000ffff25caf0bc [0x0000ffff25caee80+0x23c] 0xffff25caf0b4: adrp x1, 0xffff21730000 0xffff25caf0b8: bl 0xffff256fffc0 Which encoding byte_map_base instead of the specific oop and passing it to complete_monitor_lock_Java. So the entire story is that the predicate rule of immByteMapBase caused an incorrect ConP match when a corresponding JNIHandleBlock with an oop was allocated to the address of byte_map_base by malloc. I have a simple fix that just remove the specialized match rule for immByteMapBase below, and crashes disappeared. diff --git a/hotspot/src/cpu/aarch64/vm/aarch64.ad b/hotspot/src/cpu/aarch64/vm/aarch64.ad index d73d5d457..5305467c1 100644 --- a/hotspot/src/cpu/aarch64/vm/aarch64.ad +++ b/hotspot/src/cpu/aarch64/vm/aarch64.ad @@ -3054,11 +3054,6 @@ encode %{ assert(off == 0, "assumed offset == 0"); %} - enc_class aarch64_enc_mov_byte_map_base(iRegP dst, immByteMapBase src) %{ - MacroAssembler _masm(&cbuf); - __ load_byte_map_base($dst$$Register); - %} - enc_class aarch64_enc_mov_n(iRegN dst, immN src) %{ MacroAssembler _masm(&cbuf); Register dst_reg = as_Register($dst$$reg); @@ -4311,19 +4306,6 @@ operand immPollPage() interface(CONST_INTER); %} -// Card Table Byte Map Base -operand immByteMapBase() -%{ - // Get base of card map - predicate((jbyte*)n->get_ptr() == - ((CardTableModRefBS*)(Universe::heap()->barrier_set()))->byte_map_base); - match(ConP); - - op_cost(0); - format %{ %} - interface(CONST_INTER); -%} - // Pointer Immediate Minus One // this is used when we want to write the current PC to the thread anchor operand immP_M1() @@ -6772,20 +6754,6 @@ instruct loadConPollPage(iRegPNoSp dst, immPollPage con) ins_pipe(ialu_imm); %} -// Load Byte Map Base Constant - -instruct loadByteMapBase(iRegPNoSp dst, immByteMapBase con) -%{ - match(Set dst con); - - ins_cost(INSN_COST); - format %{ "adr $dst, $con\t# Byte Map Base" %} - - ins_encode(aarch64_enc_mov_byte_map_base(dst, con)); - - ins_pipe(ialu_imm); -%} - // Load Narrow Pointer Constant instruct loadConN(iRegNNoSp dst, immN con) Does anyone have any suggestions on this? Yadong

1 0

Re: [aarch64-port-dev ] Math: optimation for doing remainder
by Andrew Haley 02 May '24

02 May '24

On 4/12/24 11:37, Jin Guojie wrote: > According to the technical documentation of Arm N2, MSUB instruction uses the same ALU with SDIV. > After testing, it was found that the combination of MUL/SUB is much faster than MSUB. > Below is a patch I wrote to optimize the opertion of doing remainder. > Testing with actual Java programs shows that the performance of this operation has indeed been significantly improved. Interesting. I wrote a JMH test for this, and on Apple M1 separate MUL/SUB is dramatically worse: Before: Divide.iters 32 avgt 5 650.431 ± 5.890 ns/op Divide.iters 342862386 avgt 5 650.597 ± 4.460 ns/op After: Divide.iters 32 avgt 5 979.338 ± 1.266 ns/op Divide.iters 342862386 avgt 5 978.652 ± 2.005 ns/op ... which is perhaps not surprising. On another Neoverse machine I got a result very similar to yours, about 15% faster with separate MUL/SUB. To be honest with you, I hate very machine-specific performance tweaks. The biggest problem is that testing is different on every kind of machine if they all have machine-specific tweaks. Given that this is a pretty rare case, for integer modulo by a non-constant value, and that the difference is small,do you really need it? I attached a JMH test for more reliable testing. Finally, please send questions to hotspot-dev, with "AArch64" in the title, or I may not see them. -- 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

1 2

Re: [aarch64-port-dev ] Aarch64: CPU_Model support for Neoverse N1/N2/V1/V2
by Jin Guojie 30 Apr '24

30 Apr '24

Hi Andrew, We wrote a patch to improve the definition of CPU models for Arm Neoverse. Evgeny thinks it’s better to continue the review process. I submitted my OCA application 10 days ago, but it is still under review. Could you please create an issue in the JDK Bug System (JBS), so that I can submit this PR after the OCA is signed? Jin Guojie （Alibaba，hotspot developer) 2024/4/18 02:32. Astigeevich, Evgeny <eastig(a)amazon.co.uk> wrote: > I agree using enums will improve readability. > It's not been done to simplify backporting. > Could you please create a JBS issue and submit a PR? > Evgeny > On 12/04/2024, 09:22, "Jin Guojie" <jinguojie.jgj(a)alibaba-inc.com <mailto:jinguojie.jgj@alibaba-inc.com>> wrote: > Hi Evgeny, > Thanks for your great work in "8321025: Enable Neoverse N1 optimizations for Neoverse V2”. > I am currently optimizing the Aarch64 branch of hotspot. I found that there are also some constant numbers in this file vm_version_aarch64.cpp. > In order to make the programming style better, wouldn't it be better if we define these constants as macros? > Below is the code patch I wrote. Thank you for your opinion. > > Jin Guojie > > > From 2dd99c9851b0efbb3c9a8bdc95973f4646ad77c2 Mon Sep 17 00:00:00 2001From: Jin Guojie <jinguojie.jgj(a)alibaba-inc.com <mailto:jinguojie.jgj@alibaba-inc.com>> > Date: Tue, 2 Apr 2024 09:06:04 +0800 > Subject: CPU_Model support for Neoverse N1/N2/V1/V2 > --- > src/hotspot/cpu/aarch64/vm_version_aarch64.cpp | 12 +++--------- > src/hotspot/cpu/aarch64/vm_version_aarch64.hpp | 7 +++++++ > 2 files changed, 10 insertions(+), 9 deletions(-) > diff --git a/src/hotspot/cpu/aarch64/vm_version_aarch64.cpp b/src/hotspot/cpu/aarch64/vm_version_aarch64.cpp > index 18f310c746c..732020a420f 100644 > --- a/src/hotspot/cpu/aarch64/vm_version_aarch64.cpp > +++ b/src/hotspot/cpu/aarch64/vm_version_aarch64.cpp > @@ -213,12 +213,8 @@ void VM_Version::initialize() { > } > > > // Neoverse > - // N1: 0xd0c > - // N2: 0xd49 > - // V1: 0xd40 > - // V2: 0xd4f > - if (_cpu == CPU_ARM && (model_is(0xd0c) || model_is(0xd49) || > - model_is(0xd40) || model_is(0xd4f))) { > + if (_cpu == CPU_ARM && (model_is(CPU_MODEL_NEOVERSE_N1) || model_is(CPU_MODEL_NEOVERSE_N2) || > + model_is(CPU_MODEL_NEOVERSE_V1) || model_is(CPU_MODEL_NEOVERSE_V2))) { > if (FLAG_IS_DEFAULT(UseSIMDForMemoryOps)) { > FLAG_SET_DEFAULT(UseSIMDForMemoryOps, true); > } > @@ -248,9 +244,7 @@ void VM_Version::initialize() { > } > > // Neoverse > - // V1: 0xd40 > - // V2: 0xd4f > - if (_cpu == CPU_ARM && (model_is(0xd40) || model_is(0xd4f))) { > + if (_cpu == CPU_ARM && (model_is(CPU_MODEL_NEOVERSE_V1) || model_is(CPU_MODEL_NEOVERSE_V2))) { > if (FLAG_IS_DEFAULT(UseCryptoPmullForCRC32)) { > FLAG_SET_DEFAULT(UseCryptoPmullForCRC32, true); > } > diff --git a/src/hotspot/cpu/aarch64/vm_version_aarch64.hpp b/src/hotspot/cpu/aarch64/vm_version_aarch64.hpp > index 6883dc0d93e..a9821ea50c4 100644 > --- a/src/hotspot/cpu/aarch64/vm_version_aarch64.hpp > +++ b/src/hotspot/cpu/aarch64/vm_version_aarch64.hpp > @@ -114,6 +114,13 @@ enum Ampere_CPU_Model { > CPU_MODEL_AMPERE_1B = 0xac5 /* AMPERE_1B core Implements ARMv8.7 with CSSC, MTE, SM3/SM4 extensions */ > }; > > +enum Neoverse_CPU_Model { > + CPU_MODEL_NEOVERSE_N1 = 0xd0c, > + CPU_MODEL_NEOVERSE_N2 = 0xd49, > + CPU_MODEL_NEOVERSE_V1 = 0xd40, > + CPU_MODEL_NEOVERSE_V2 = 0xd4f, > +}; > + > #define CPU_FEATURE_FLAGS(decl) \ > decl(FP, fp, 0) \ > decl(ASIMD, asimd, 1) \ > -- > 2.39.3 Amazon Development Centre (London) Ltd. Registered in England and Wales with registration number 04543232 with its registered office at 1 Principal Place, Worship Street, London EC2A 2FA, United Kingdom.

2 2

Linux aarch64 Virtualization detection
by Baesken, Matthias 13 Jan '23

13 Jan '23

Hi , maybe someone can help with the following topic. On x86_64 there is for quite some time coding in the JVM to detect the virtualization (e.g. VMWare, KVM, Xen …) . The info is later used in hs_err file output / jfr etc . See https://github.com/openjdk/jdk/blob/34cdda5b8359cce33c2d4f92a41a620aea4f96e… https://github.com/openjdk/jdk/blob/34cdda5b8359cce33c2d4f92a41a620aea4f96e… (x86_64 uses the cpuid call) On Linux ppc64(le) we have something similar (but this parses some /proc file system location ). I think it would be nice to have the Virtualization detection on Linux aarch64 too . Is someone aware of some good ways to get the info on aarch64 ? On OS level , we can for example call this to get the info : sudo dmidecode -s system-product-name KVM Virtual Machine (but calling stuff like dmidecode from the JVM is not really an option , and it also needs privileges [sudo] ) . For the JVM we need something more lightweight (like cpuid call on x86_64 , or parsing a file on ppc64(le) ) . Best regards, Matthias

1 0

Fwd: Does OpenJDK have plans to provide Windows Arm64EC port?
by Andrew Haley 07 Sep '22

07 Sep '22

-------- Forwarded Message -------- From: Glavo <zjx001202(a)gmail.com> Date: Wed, 7 Sep 2022 15:29:41 +0800 Message-ID: <CAJL5A3=_4dNsy8OnHR_zi5U_yHumLzfiuwDMHmr-VF0_FaC7Bg(a)mail.gmail.com> Subject: Does OpenJDK have plans to provide Windows Arm64EC port? To: aarch64-port-dev(a)openjdk.org Many native libraries do not yet support Windows on Arm, but the performance of executing Java applications through x86 emulation is very poor. If OpenJDK provides an Arm64EC port, the above problem would be solved, so I wonder if anyone is working on this.

2 1

Re: [aarch64-port-dev ] 8u332 Release
by Thorsten Glaser 06 May '22

06 May '22

Hi list(s), On Wed, 20 Apr 2022, Andrew Hughes wrote: > I have pushed jdk8u332-b09 with the April security updates to the > monojdk8u repository: any idea when the aarch64-shenandoah-jdk8u332-* will be available? Thanks in advance, //mirabilos (for Debian) -- Infrastrukturexperte • tarent solutions GmbH Am Dickobskreuz 10, D-53121 Bonn • http://www.tarent.de/ Telephon +49 228 54881-393 • Fax: +49 228 54881-235 HRB AG Bonn 5168 • USt-ID (VAT): DE122264941 Geschäftsführer: Dr. Stefan Barth, Kai Ebenrett, Boris Esser, Alexander Steeg **************************************************** /⁀\ The UTF-8 Ribbon ╲ ╱ Campaign against Mit dem tarent-Newsletter nichts mehr verpassen: ╳ HTML eMail! Also, https://www.tarent.de/newsletter ╱ ╲ header encryption! ****************************************************

3 3

Re: [aarch64-port-dev ] Simple HTTP server app crashes on JDK 11 and 8 on OSv AArch64
by Andrew Haley 07 Mar '22

07 Mar '22

On 3/6/22 05:33, Waldek Kozaczuk wrote: > Thanks for this hint. I think I have solved this puzzle. > > Once I got hold of the JDK debuginfo files and identified the patching code > - MacroAssembler::pd_patch_instruction(), I was able to put a breakpoint in > it and see something very revealing: > > #0 MacroAssembler::pd_patch_instruction_size (branch=0x20000879465c > "\351\377\237\322\351\377\277\362\351\377\337\362\n\243\352\227\037", > target=*0xffffa00042c862e0* "\020zB") at > src/hotspot/cpu/aarch64/macroAssembler_aarch64.cpp:75 > #1 0x0000100000bc13cc in MacroAssembler::pd_patch_instruction (file=0x0, > line=0, target=0xffffa00042c862e0 "\020zB", branch=<optimized out>) > at src/hotspot/cpu/aarch64/macroAssembler_aarch64.hpp:626 > #2 NativeMovConstReg::set_data (this=0x20000879465c, x=-105551995837728) > at src/hotspot/cpu/aarch64/nativeInst_aarch64.cpp:262 > #3 0x0000100000850bd0 in CompiledIC::set_ic_destination_and_value > (value=0xffffa00042c862e0, > entry_point=0x20000823d290 > "(\b@\271\b\001]\322*\005@\371\037\001\n\353,\001", > <incomplete sequence \371\200>, this=<optimized out>) > at src/hotspot/share/code/compiledIC.hpp:193 > #4 ICStub::finalize (this=<optimized out>) at > src/hotspot/share/code/icBuffer.cpp:91 > #5 ICStubInterface::finalize (this=<optimized out>, self=<optimized out>) > at src/hotspot/share/code/icBuffer.cpp:43 > #6 0x0000100000e30958 in StubQueue::stub_finalize > (this=0xffffa00041555300, s=<optimized out>) at > src/hotspot/share/code/stubs.hpp:168 > #7 StubQueue::remove_first (this=0xffffa00041555300) at > src/hotspot/share/code/stubs.cpp:175 > .... > > The corresponding crash value of X9 was this: > > *0x0000a00042c862e0* > > vs the target argument of pd_patch_instruction() (see above in the > backtrace): > > *0xffffa00042c862e0* > > Now given this comment: > > // Move a constant pointer into r. In AArch64 mode the virtual > // address space is 48 bits in size, so we only need three > // instructions to create a patchable instruction sequence that can > // reach anywhere. > > and this fragment of pd_patch_instruction() - > https://github.com/openjdk/jdk17u/blob/6f0f42630eac1febf562062afc523fdf3d2a… > > it seems that the code to load x8 register with an address gets patched > with 0x0000a00042c862e0 instead of 0xffffa00042c862e0. It is interesting > that this assert - > https://github.com/openjdk/jdk17u/blob/6f0f42630eac1febf562062afc523fdf3d2a… > - does not get hit. It won't unless you run a debug build. If I were you I'd do that soon. > The bottom line is that the valid address 0xffffa00042c862e0 gets truncated > to 0x0000a00042c862e0 I guess based on the assumption that in Linux all > userspace addresses are 48-bits long (see > https://www.kernel.org/doc/html/latest/arm64/memory.html) That's right. > In OSv > unikernel, there is no separation between user space and kernel space, and > it happens that addresses returned by malloc fall into this range: > > 0xffffa00000000000 - 0xffffafffffffffff > > So I guess the only solution to fix it on the OSv side would be to tweak > its virtual memory mapping for mallocs and make sure it never uses virtual > addresses > 48-bits. Is that possible? AFAIK AArch64 supports two VA subranges, • The bottom VA range runs up from address 0x0000_0000_0000_0000 . With the maximum address width of 48 bits this gives a VA range of 0x0000_0000_0000_0000 to 0x0000_FFFF_FFFF_FFFF . • The top VA subrange runs up to address 0xFFFF_FFFF_FFFF_FFFF . With the maximum address width of 48 bits this gives a VA range of 0xFFFF_0000_0000_0000 to 0xFFFF_FFFF_FFFF_FFFF . Do you support both subranges simultaneously in OSy? > Could you confirm my analysis? If you can. AArch64 OpenJDK uses 48-bit userspace. We did have a patch to allow 64-bit addresses, but there wasn't any point at the time. But in any case, it'd be a really good idea to allow apps designed for 48-bit userspace to work on OSy. This might be a good time for us to resurrect the 64-bit address patch, but that might not help you much, because I guess you'll want older Java versions to work. -- 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 3

Re: [aarch64-port-dev ] Simple HTTP server app crashes on JDK 11 and 8 on OSv AArch64
by Andrew Haley 05 Mar '22

05 Mar '22

On 3/5/22 10:08, Andrew Haley wrote: > On 3/5/22 05:25, Waldek Kozaczuk wrote: >> Any ideas on how to debug it further? >> >> Any help is greatly appreciated, >> Waldek > > Is is possible to attach gdb? Is it possible to get a core dump? > > I see no attached file. Please put it on a file sharing system so we > can see it. Having said that, it looks like there may be a problem when patching inline cache, and that may be due to a problem with cache flushing. Maybe __builtin___clear_cache is flaky. The caller is here: address MacroAssembler::ic_call(address entry, jint method_index) { RelocationHolder rh = virtual_call_Relocation::spec(pc(), method_index); movptr(rscratch2, (uintptr_t)Universe::non_oop_word()); return trampoline_call(Address(entry, rh)); } This generates a sequence that gets patched at runtime when a call is resolved. The compiled sequence initially looks like this: 0xffffa5be35e0: mov x9, #0xffff // #65535 0xffffa5be35e4: movk x9, #0xffff, lsl #16 0xffffa5be35e8: movk x9, #0xffff, lsl #32 0xffffa5be35ec: bl 0xffffa5bd23c0 then it gets patched to look like this: 0xffffa5be35e0: mov x9, #0x1b58 // #7000 0xffffa5be35e4: movk x9, #0x4, lsl #16 0xffffa5be35e8: movk x9, #0x8, lsl #32 0xffffa5be35ec: bl 0xffffa5be36e0 It looks to me as though some threads aren't seeing the patched code, and this could well be a kernel problem. -- 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

1 0

Simple HTTP server app crashes on JDK 11 and 8 on OSv AArch64
by Waldek Kozaczuk 05 Mar '22

05 Mar '22

Hi, I am one of the committers to the OSv project (http://osv.io/) OSv is is a Linux-compatible unikernel. OSv has been able to run unmodified Linux version of Java very well since early on including Java 7 all the way to Java 14 (or possibly including the latest one) on x86_64. However, I have discovered some problems trying to run JVM apps on OSv aarch64 port which probably has some gaps compared to x64_64. And I am looking for some hints or help, in general, to figure out what exactly might be the cause of this issue. In essence, a simple HTTP server app (see the code in the link - https://github.com/cloudius-systems/osv-apps/blob/master/java-httpserver/Ht…) crashes once I sent some requests using curl. The crash looks like this on openjdk11: OSv v0.55.0-241-g8d4039b3 eth0: 192.168.122.15 Booted up in 61.89 ms Cmdline: /usr/lib/jvm/java/bin/java -cp /java-httpserver HttpServerApp ! Listening on port 8000 ... # # A fatal error has been detected by the Java Runtime Environment: # # SIGSEGV (0xb) at pc=0x0000200009248830, pid=2, tid=47 # # JRE version: OpenJDK Runtime Environment (11.0.10+9) (build 11.0.10+9-Ubuntu-0ubuntu1.20.10) # Java VM: OpenJDK 64-Bit Server VM (11.0.10+9-Ubuntu-0ubuntu1.20.10, mixed mode, tiered, compressed oops, serial gc, linux-aarch64) # Problematic frame: # v ~BufferBlob::I2C/C2I adapters # # Core dump will be written. Default location: core.2 (may not exist) # # An error report file with more information is saved as: # /tmp/hs_err_pid2.log Could not load hsdis-aarch64.so; library not loadable; PrintAssembly is disabled # # If you would like to submit a bug report, please visit: # https://bugs.launchpad.net/ubuntu/+source/openjdk-lts # # # A fatal error has been detected by the Java Runtime Environment: # # SIGSEGV (0xb) at pc=0x0000200009248830, pid=2, tid=47 # # JRE version: OpenJDK Runtime Environment (11.0.10+9) (build 11.0.10+9-Ubuntu-0ubuntu1.20.10) # Java VM: OpenJDK 64-Bit Server VM (11.0.10+9-Ubuntu-0ubuntu1.20.10, mixed mode, tiered, compressed oops, serial gc, linux-aarch64) # Problematic frame: # v ~BufferBlob::I2C/C2I adapters # # Core dump will be written. Default location: core.2 (may not exist) # # If you would like to submit a bug report, please visit: # https://bugs.launchpad.net/ubuntu/+source/openjdk-lts # --------------- S U M M A R Y ------------ Command Line: HttpServerApp Host: AArch64, 1 cores, 1G, Linux Time: Sat Apr 24 04:10:05 2021 UTC elapsed time: 13.255518 seconds (0d 0h 0m 13s) --------------- T H R E A D --------------- Current thread (0xffff900042e8b000): JavaThread "HTTP-Dispatcher" [_thread_in_Java, id=47, stack(0x000020007a801000,0x000020007aa00000)] Stack: [0x000020007a801000,0x000020007aa00000], sp=0x000020007a9fdb40, free space=2034k Native frames: (J=compiled Java code, A=aot compiled Java code, j=interpreted, Vv=VM code, C=native code) v ~BufferBlob::I2C/C2I adapters J 356 c1 java.lang.invoke.InvokerBytecodeGenerator.emitStaticInvoke(Ljava/lang/invoke/MemberName;Ljava/lang/invoke/LambdaForm$Name;)V java.base(a)11.0.10 (258 bytes) @ 0x000020000982c21c [0x000020000982be00+0x000000000000041c] C 0x0000200078a6de18 siginfo: si_signo: 11 (SIGSEGV), si_code: 2057296688 (unknown), si_errno: 8192, si_addr: 0x0000a00042f0f000 Please see this issue details for full output including core dump and state of registers - https://github.com/cloudius-systems/osv/issues/1157#issue-933793577. It is interesting, that when I disable JIT by adding '-X int' to the java command line, the app works flawlessly. That makes me thinks that the problem most likely happens somewhere in JVM when bytecode is translated into aarch64 machine code to be exxecuted later. I wonder if possibly it has to do with ARM I-cache/D-cache synchronization (see https://community.arm.com/developer/ip-products/processors/b/processors-ip-…) which somehow is not well supported by OSv. I actually had to fix a similar problem in OSv MMU code (see https://github.com/cloudius-systems/osv/commit/71919b9bb50604da56dec0ebe6cd…) to make sure that any page fault to populate page with executable permission calls *__builtin___clear_cache*() which was essential when loading any application ELF file in memory. I am guessing, in case of JIT it must be more complicated but presumably JVM also needs to clear I-cache after the machine code is generated and loaded into memory before execution. Obviously it is still my speculation. But that is where I need more hints and possibly pointers to the JVM code to help me understand what is going on. It would be nice if I could understand how the JIT works to some extent especially as far as interactions with Linux kernel go and what possibly might be wrong/missing in OSv aarch64 port. I am also speculating that JDK 8 crashes on OSv even though looking different might be have same root cause: OSv v0.55.0-266-g5aedb749 eth0: 192.168.122.15 Booted up in 92.21 ms Cmdline: java.so -cp /java-example Hello java.so: Starting JVM app using: io/osv/nonisolated/RunNonIsolatedJvmApp java.so: Setting Java system classloader to NonIsolatingOsvSystemClassLoader # # A fatal error has been detected by the Java Runtime Environment: # # Internal Error (assembler_aarch64.hpp:237), pid=2, tid=0xffffa0004109c630 # guarantee(val < (1U << nbits)) failed: Field too big for insn # # JRE version: (8.0_282-b08) (build ) # Java VM: OpenJDK 64-Bit Server VM (25.282-b08 mixed mode linux-aarch64 compressed oops) # Core dump written. Default location: //core or core.2 # # An error report file with more information is saved as: # /tmp/hs_err_pid2.log # # If you would like to submit a bug report, please visit: # http://bugreport.java.com/bugreport/crash.jsp # Aborted [backtrace] 0x000010000097a750 <???+9938768> 0x0000100000b90590 <???+12125584> See https://github.com/cloudius-systems/osv/issues/1145 for details. Any help would be greatly appreciated. Best regards, Waldek

2 3