JDK-8304389 : [11u] Crash on Windows in C2 compiled code after 8248238 and 8218431
  • Type: Bug
  • Component: hotspot
  • Sub-Component: compiler
  • Affected Version: 11.0.19
  • Priority: P2
  • Status: Resolved
  • Resolution: Fixed
  • OS: windows
  • CPU: x86_64
  • Submitted: 2023-03-17
  • Updated: 2023-03-22
  • Resolved: 2023-03-21
The Version table provides details related to the release that this issue/RFE will be addressed.

Unresolved : Release in which this issue/RFE will be addressed.
Resolved: Release in which this issue/RFE has been resolved.
Fixed : Release in which this issue/RFE has been fixed. The release containing this fix may be available for download as an Early Access Release or a General Availability Release.

To download the current JDK release, click here.
JDK 11
11.0.19 b06Fixed
Related Reports
Relates :  
Relates :  
Relates :  
Description
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
endif

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
#
Comments
Changeset: f1c92b47 Author: Goetz Lindenmaier <goetz@openjdk.org> Date: 2023-03-21 14:42:22 +0000 URL: https://git.openjdk.org/jdk11u/commit/f1c92b472d03e3387237cc4d7c6401310cf86f19
21-03-2023

To answer my own question, the _WIN64 ABI C calling convention settings in C2 should have been enabled since jdk 16, with no problems reported, so this appears to affect 11.0.19 only.
21-03-2023

ILW = crash; one test, Windows x64 only; no workaround = HLH = P2
20-03-2023

Doesn't this also affect the latest jdk21?
17-03-2023

A pull request was submitted for review. URL: https://git.openjdk.org/jdk11u/pull/70 Date: 2023-03-17 07:47:44 +0000
17-03-2023