Uploaded image for project: 'JDK'
  1. JDK
  2. JDK-8335221

Some C2 intrinsics incorrectly assume that type argument is compile-time constant

    XMLWordPrintable

Details

    • master

    Backports

      Description

        While testing Leyden Early Release problems were found in some C2 intrinsics.
        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 JDK-8309130 in JDK 22.

        Attachments

          Issue Links

            Activity

              People

                kvn Vladimir Kozlov
                kvn Vladimir Kozlov
                Votes:
                0 Vote for this issue
                Watchers:
                5 Start watching this issue

                Dates

                  Created:
                  Updated:
                  Resolved: