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

[11u] Crash on Windows in C2 compiled code after 8248238 and 8218431



    • b06
    • x86_64
    • windows



        We recently see crashes on windows in one of our tests with 11.0.19.

        This is because adlc generates different code since backport of "JDK-8218431: Improved platform checking in makefiles":

        --- adfiles-before/ad_x86.cpp
        +++ adfiles-after/ad_x86.cpp
        @@ -2697,12 +2697,12 @@
           'C', // RCX_H
           'E', // RBX
           'E', // RBX_H
        - 'C', // RDI
        - 'C', // RDI_H
        + 'E', // RDI
        + 'E', // RDI_H
           'C', // RDX
           'C', // RDX_H
        - 'C', // RSI
        - 'C', // RSI_H
        + 'E', // RSI
        + 'E', // RSI_H
           'C', // RAX
           'C', // RAX_H
           'E', // RBP

        But 8218431 is not buggy, it just introduced the function "isTargetCpuBits" to the makefiles.
        This function was already used, but always evaluated to false as the implementation was missing.
        Now, with the implementation, it evaluated correctly and the build effectively changed.

        This happens in GensrcAdlc.gmk, where "JDK-8248238: Implementation: JEP 388: Windows AArch64 Support"
        introduced this check:

        ifeq ($(call isTargetCpuBits, 64), true)
          ADLCFLAGS += -D_WIN64=1

        Thus, by adding "isTargetCpuBits" in 8218431, now _WIN64 is passed to adlc on windows x86_64.
        Unfortunately, 8248238 was supposed to not change anything else than adding the windows aarch64 port, but it did change windows x86_64. This affects the #ifdef in x86_64.ad line 89.

        Undoing this change assures more registers are spilled around a call and fixes the issue.

        There was a bigger rework of this code in jdk16: "JDK-8256205: Simplify compiler calling convention handling" that probably includes the real fix for this issue. This can not be backported because it requires Solaris to be removed and also is quite complex.

        # A fatal error has been detected by the Java Runtime Environment:
        # EXCEPTION_ACCESS_VIOLATION (0xc0000005) at pc=0x0000017b904f87a0, pid=147636, tid=144532
        # JRE version: OpenJDK Runtime Environment (11.0.20) (build 11.0.20-internal+0-adhoc.GLOBALopenjdk.jdk11u-dev)
        # Java VM: OpenJDK 64-Bit Server VM (11.0.20-internal+0-adhoc.GLOBALopenjdk.jdk11u-dev, mixed mode, tiered, compressed oops, serial gc, windows-amd64)
        # Problematic frame:
        # J 6396% c2 sun.awt.geom.AreaOp.pruneEdges(Ljava/util/Vector;)Ljava/util/Vector; java.desktop@11.0.20-internal (987 bytes) @ 0x0000017b904f87a0 [0x0000017b904f7720+0x0000000000001080]
        # Core dump will be written. Default location: D:\...\hs_err_pid147636.mdmp
        # If you would like to submit a bug report, please visit:
        # https://bugreport.java.com/bugreport/crash.jsp


          Issue Links



                goetz Goetz Lindenmaier
                goetz Goetz Lindenmaier
                0 Vote for this issue
                6 Start watching this issue