-
Bug
-
Resolution: Fixed
-
P3
-
22, 23, 24
-
b05
Issue | Fix Version | Assignee | Priority | Status | Resolution | Resolved In Build |
---|---|---|---|---|---|---|
JDK-8336132 | 23.0.1 | Vladimir Kozlov | P3 | Resolved | Fixed | b03 |
JDK-8335556 | 23 | Vladimir Kozlov | P3 | Resolved | Fixed | b30 |
inline_array_partition() and inline_array_sort() incorrectly assume that `elementType` argument is always compile-time constant. Which is not true for Leyden (and in general) when constant folding optimization is switched off (or did not executed for particular type).
Note, other intrinsics are very careful about that. Add similar check to inline_array_partition() and inline_array_sort().
As result we crash in `elem_klass->const_oop()->as_instance()->java_mirror_type();` because _oop_const is NULL (see attached hs_err_pid77994.log file):
# SIGSEGV (0xb) at pc=0x0000000103773f70, pid=77994, tid=27651
#
# JRE version: Java(TM) SE Runtime Environment (24.0) (fastdebug build 24-internal-2024-06-26-1746082...)
# Java VM: Java HotSpot(TM) 64-Bit Server VM (fastdebug 24-internal-2024-06-26-1746082..., mixed mode, sharing, tiered, compressed oops, compressed class ptrs, g1 gc, bsd-aarch64)
# Problematic frame:
# V [libjvm.dylib+0xc6ff70] LibraryCallKit::inline_array_sort()+0x254
...
Current CompileTask:
C2: F11481 C2 Q0 S1 3734 b 4 java.util.DualPivotQuicksort::sort (685 bytes)
Stack: [0x0000000171074000,0x0000000171277000], sp=0x00000001712740b0, free space=2048k
Native frames: (J=compiled Java code, j=interpreted, Vv=VM code, C=native code)
V [libjvm.dylib+0xc6ff70] LibraryCallKit::inline_array_sort()+0x254
V [libjvm.dylib+0xc6a640] LibraryIntrinsic::generate(JVMState*)+0x168
V [libjvm.dylib+0x634260] Parse::do_call()+0x898
An other problem was that null_check() (which adds new control subgraph) was executed in these intrinsic before bailouts from intrinsic generation. We hit next assert in such case:
# Internal Error (/work/leyden/open/src/hotspot/share/opto/library_call.cpp:139), pid=85284, tid=28163
# assert(ctrl == kit.control()) failed: Control flow was added although the intrinsic bailed out
#
# JRE version: Java(TM) SE Runtime Environment (24.0) (fastdebug build 24-internal-2024-06-26-1746082....)
...
Current CompileTask:
C2: F10709 C3 Q0 S0 3734 b 4 java.util.DualPivotQuicksort::sort (685 bytes)
Stack: [0x000000016f0a4000,0x000000016f2a7000], sp=0x000000016f2a3ed0, free space=2047k
Native frames: (J=compiled Java code, j=interpreted, Vv=VM code, C=native code)
V [libjvm.dylib+0x11d5634] VMError::report_and_die(int, char const*, char const*, char*, Thread*, unsigned char*, void*, void*, char const*, int, unsigned long)+0x544 (library_call.cpp:139)
V [libjvm.dylib+0x11d5de4] VMError::report_and_die(Thread*, unsigned int, unsigned char*, void*, void*)+0x0
V [libjvm.dylib+0x58f11c] print_error_for_unit_test(char const*, char const*, char*)+0x0
V [libjvm.dylib+0xc6abcc] LibraryIntrinsic::generate(JVMState*)+0x6b4
V [libjvm.dylib+0x6342a0] Parse::do_call()+0x898
These 2 intrinsics were added by
- backported by
-
JDK-8335556 Some C2 intrinsics incorrectly assume that type argument is compile-time constant
- Resolved
-
JDK-8336132 Some C2 intrinsics incorrectly assume that type argument is compile-time constant
- Resolved
- relates to
-
JDK-8334809 Spring Boot crashes with Leyden EA
- Resolved
-
JDK-8309130 x86_64 AVX512 intrinsics for Arrays.sort methods (int, long, float and double arrays)
- Resolved
- links to
-
Commit openjdk/jdk/166f9d9a
-
Commit openjdk/jdk/b6d0ead9
-
Review openjdk/jdk/19918
-
Review openjdk/jdk/19975