JDK-8322985 : [BACKOUT] 8318562: Computational test more than 2x slower when AVX instructions are used
  • Type: Sub-task
  • Component: hotspot
  • Sub-Component: compiler
  • Affected Version: 17.0.11,21.0.2,22,23
  • Priority: P1
  • Status: Resolved
  • Resolution: Fixed
  • CPU: x86
  • Submitted: 2024-01-04
  • Updated: 2024-01-08
  • Resolved: 2024-01-05
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 17 JDK 21 JDK 22 JDK 23
17.0.11Fixed 21.0.2Fixed 22Fixed 23 masterFixed
Related Reports
Duplicate :  
JDK-8322479 - Regression in SPECjvm2008-MonteCarlo-ParGC on Linux-x64
Relates :  
JDK-8318562 - Computational test more than 2x slower when AVX instructions are used
Description
JDK-8318562 broke implicit null checking for floating point conversions (cvt instructions).

Tests crash with SEGV in 
#
# A fatal error has been detected by the Java Runtime Environment:
#
#  SIGSEGV (0xb) at pc=0x00007fac4cda8afe, pid=3587986, tid=3589638
#
# JRE version: Java(TM) SE Runtime Environment (22.0+27) (fastdebug build 22-ea+27-2262)
# Java VM: Java HotSpot(TM) 64-Bit Server VM (fastdebug 22-ea+27-2262, compiled mode, sharing, compressed oops, compressed class ptrs, g1 gc, linux-amd64)
# Problematic frame:
# J 18755 c2 java.awt.geom.Line2D.intersectsLine(Ljava/awt/geom/Line2D;)Z java.desktop@22-ea (36 bytes) @ 0x00007fac4cda8afe [0x00007fac4cda8ac0+0x000000000000003e]
#
# Core dump will be written. Default location: Core dumps may be processed with "/opt/core.sh %p" (or dumping to /opt/mach5/mesos/work_dir/slaves/0db9c48f-6638-40d0-9a4b-bd9cc7533eb8-S39947/frameworks/1735e8a2-a1db-478c-8104-60c8b0af87dd-0196/executors/583b6396-b783-4894-899d-abfe6471de40/runs/610a295e-384f-48df-9949-0e9d7ebd14f1/testoutput/test-support/jck_runtime_api_java_awt/core.3587986)
#
# If you would like to submit a bug report, please visit:
#   https://bugreport.java.com/bugreport/crash.jsp
#

---------------  S U M M A R Y ------------

Command Line: --enable-preview -Djava.awt.headless=true -Xcomp -ea -esa -XX:CompileThreshold=100 -XX:+UnlockExperimentalVMOptions -XX:-TieredCompilation -XX:MaxRAMPercentage=4.16667 -XX:+EnableDynamicAgentLoading -XX:TieredStopAtLevel=1 -Xms32m -Xmx1024m -Djdk.attach.allowAttachSelf=true -Djava.security.properties=/opt/mach5/mesos/work_dir/jib-master/install/jck/22/b14/extra/bundles/JCK-extra-22.zip/JCK-extra-22/extra.security.properties -Djava.security.policy=/opt/mach5/mesos/work_dir/jib-master/install/jck/22/b14/bundles/JCK-runtime-22.jar/JCK-runtime-22/lib/jck.policy com.sun.jck.lib.multijvm.group.wrapper.ActiveMain -id 1 -host 100.73.200.120 -port 33093 -idleTimeout 1200000 -testTimeout 6000000

Host: ol9-x64-558391, AMD EPYC 7J13 64-Core Processor, 12 cores, 23G, Oracle Linux Server release 9.2
Time: Sat Dec  9 22:44:58 2023 UTC elapsed time: 198.110719 seconds (0d 0h 3m 18s)

---------------  T H R E A D  ---------------

Current thread (0x00007faba802a200):  JavaThread "CommandExecutor executeThread for command args: [-loadDir, /opt/mach5/mesos/work_dir/jib-master/install/jck/22/b14/bundles/JCK-runtime-22.jar/JCK-runtime-22/classes:, javasoft.sqe.tests.api.java.awt.geom.Line2DFloat.IntersectsLineTest, -TestCaseID, testCase4]"        [_thread_in_Java, id=3589638, stack(0x00007fac33a3f000,0x00007fac33b3f000) (1024K)]

Stack: [0x00007fac33a3f000,0x00007fac33b3f000],  sp=0x00007fac33b3d3a0,  free space=1016k
Native frames: (J=compiled Java code, j=interpreted, Vv=VM code, C=native code)
J 18755 c2 java.awt.geom.Line2D.intersectsLine(Ljava/awt/geom/Line2D;)Z java.desktop@22-ea (36 bytes) @ 0x00007fac4cda8afe [0x00007fac4cda8ac0+0x000000000000003e]
j  javasoft.sqe.tests.api.java.awt.geom.Line2DFloat.IntersectsLineTest.testCase4()Ljavasoft/sqe/javatest/Status;+63
J 3779 c2 java.lang.invoke.DirectMethodHandle$Holder.invokeVirtual(Ljava/lang/Object;Ljava/lang/Object;)Ljava/lang/Object; java.base@22-ea (14 bytes) @ 0x00007fac4d6b6b54 [0x00007fac4d6b6ae0+0x0000000000000074]
J 3782 c2 java.lang.invoke.LambdaForm$MH+0x00007fabf300e000.invoke(Ljava/lang/Object;Ljava/lang/Object;)Ljava/lang/Object; java.base@22-ea (35 bytes) @ 0x00007fac4d6b9d44 [0x00007fac4d6b9ca0+0x00000000000000a4]
J 2070 c2 java.lang.invoke.Invokers$Holder.invokeExact_MT(Ljava/lang/Object;Ljava/lang/Object;Ljava/lang/Object;)Ljava/lang/Object; java.base@22-ea (23 bytes) @ 0x00007fac4d2bcb84 [0x00007fac4d2bcb00+0x0000000000000084]
J 9466 c2 jdk.internal.reflect.DirectMethodHandleAccessor.invoke(Ljava/lang/Object;[Ljava/lang/Object;)Ljava/lang/Object; java.base@22-ea (92 bytes) @ 0x00007fac4dff7994 [0x00007fac4dff78c0+0x00000000000000d4]
J 3772 c2 javasoft.sqe.javatest.lib.MultiTest.invokeTestCase(Ljava/lang/reflect/Method;)Ljavasoft/sqe/javatest/Status; (15 bytes) @ 0x00007fac4d6b56e8 [0x00007fac4d6b5520+0x00000000000001c8]
J 17623 c2 javasoft.sqe.javatest.lib.MultiTest.run([Ljava/lang/String;Ljava/io/PrintWriter;Ljava/io/PrintWriter;)Ljavasoft/sqe/javatest/Status; (293 bytes) @ 0x00007fac4df695dc [0x00007fac4df692c0+0x000000000000031c]
J 3692 c2 java.lang.invoke.LambdaForm$DMH+0x00007fabf300c400.invokeVirtual(Ljava/lang/Object;Ljava/lang/Object;Ljava/lang/Object;Ljava/lang/Object;Ljava/lang/Object;)Ljava/lang/Object; java.base@22-ea (20 bytes) @ 0x00007fac4d68db40 [0x00007fac4d68dae0+0x0000000000000060]
J 17605 c2 java.lang.invoke.LambdaForm$MH+0x00007fabf3291000.invoke(Ljava/lang/Object;Ljava/lang/Object;Ljava/lang/Object;Ljava/lang/Object;Ljava/lang/Object;)Ljava/lang/Object; java.base@22-ea (103 bytes) @ 0x00007fac4d77b968 [0x00007fac4d77b880+0x00000000000000e8]
J 3739 c2 java.lang.invoke.LambdaForm$MH+0x00007fabf300dc00.invokeExact_MT(Ljava/lang/Object;Ljava/lang/Object;Ljava/lang/Object;Ljava/lang/Object;Ljava/lang/Object;Ljava/lang/Object;)Ljava/lang/Object; java.base@22-ea (28 bytes) @ 0x00007fac4d69f6a4 [0x00007fac4d69f600+0x00000000000000a4]
J 9466 c2 jdk.internal.reflect.DirectMethodHandleAccessor.invoke(Ljava/lang/Object;[Ljava/lang/Object;)Ljava/lang/Object; java.base@22-ea (92 bytes) @ 0x00007fac4dff7a48 [0x00007fac4dff78c0+0x0000000000000188]
J 8009 c2 com.sun.jck.lib.ExecJCKTestSameJVMCmd$Version2Test.execute([Ljava/lang/String;Ljava/io/PrintWriter;Ljava/io/PrintWriter;)Lcom/sun/javatest/Status; (137 bytes) @ 0x00007fac4dec8540 [0x00007fac4dec7ec0+0x0000000000000680]
J 3685 c2 com.sun.jck.lib.ExecJCKTestSameJVMCmd$StandardTest.run([Ljava/lang/String;Ljava/io/PrintWriter;Ljava/io/PrintWriter;)Lcom/sun/javatest/Status; (320 bytes) @ 0x00007fac4d68576c [0x00007fac4d685700+0x000000000000006c]
J 4069 c2 com.sun.jck.lib.ExecJCKTestSameJVMCmd.execute(Ljava/lang/ClassLoader;Ljava/lang/String;[Ljava/lang/String;Ljava/io/PrintWriter;Ljava/io/PrintWriter;I)Lcom/sun/javatest/Status; (414 bytes) @ 0x00007fac4d7547c4 [0x00007fac4d754480+0x0000000000000344]
J 8004 c2 com.sun.jck.lib.ExecJCKTestSameJVMCmd.run([Ljava/lang/String;Ljava/io/PrintWriter;Ljava/io/PrintWriter;)Lcom/sun/javatest/Status; (1182 bytes) @ 0x00007fac4ded3288 [0x00007fac4decf700+0x0000000000003b88]
J 3350 c2 com.sun.javatest.agent.Agent$CommandExecutor.lambda$execute$1()V (190 bytes) @ 0x00007fac4d5a5fec [0x00007fac4d5a5f20+0x00000000000000cc]
J 18700 c2 com.sun.javatest.agent.Agent$CommandExecutor$$Lambda+0x00007fabf3009f20.run()V (8 bytes) @ 0x00007fac4e55828c [0x00007fac4e558240+0x000000000000004c]
J 2816 c2 java.lang.Thread.run()V java.base@22-ea (23 bytes) @ 0x00007fac4d487264 [0x00007fac4d4871c0+0x00000000000000a4]
v  ~StubRoutines::call_stub 0x00007fac4cc4bd21
V  [libjvm.so+0xe82f59]  JavaCalls::call_helper(JavaValue*, methodHandle const&, JavaCallArguments*, JavaThread*)+0x4a9
V  [libjvm.so+0xe83615]  JavaCalls::call_virtual(JavaValue*, Klass*, Symbol*, Symbol*, JavaCallArguments*, JavaThread*)+0x345
V  [libjvm.so+0xe83836]  JavaCalls::call_virtual(JavaValue*, Handle, Klass*, Symbol*, Symbol*, JavaThread*)+0x76
V  [libjvm.so+0xfec673]  thread_entry(JavaThread*, JavaThread*)+0x93
V  [libjvm.so+0xeb7fcc]  JavaThread::thread_main_inner()+0xcc
V  [libjvm.so+0x179cbb6]  Thread::call_run()+0xb6
V  [libjvm.so+0x14a6f47]  thread_native_entry(Thread*)+0x127

siginfo: si_signo: 11 (SIGSEGV), si_code: 1 (SEGV_MAPERR), si_addr: 0x000000000000000c

Registers:
RAX=0x00007fabe9701478, RBX=0x00007fabe9701478, RCX=0xfffffffffffffff5, RDX=0x0000000000000000
RSP=0x00007fac33b3d3a0, RBP=0x00007fac33b3d418, RSI=0x00000000fff38d78, RDI=0x00007faba802a200
R8 =0x00007faba8030260, R9 =0x0000000000000004, R10=0x00007fabf2000000, R11=0x00007fac4cda8ae0
R12=0x0000000000000000, R13=0x00007fac33b3d3c0, R14=0x00007fabe88907c8, R15=0x00007faba802a200
RIP=0x00007fac4cda8afe, EFLAGS=0x0000000000010202, CSGSFS=0x002b000000000033, ERR=0x0000000000000004
  TRAPNO=0x000000000000000e
Comments
Thanks [~sviswanathan]! I created the REDO JDK-8323116.
08-01-2024
[~thartmann] Firstly, thanks a lot for quickly jumping in and taking care of this through backout and multiple backports. The attached cvtfix.patch on top of 8318562 fixes the issue and retains the performance improvement. It basically forces the memory operand to be loaded in a register for AVX > 0 and only emits the register version while retaining the correct idiom for the register format to get the best perf. I will plan to prepare a redo patch sometime in near future and send towards jdk mainline.
05-01-2024
A pull request was submitted for review. URL: https://git.openjdk.org/jdk21u/pull/431 Date: 2024-01-05 17:52:37 +0000
05-01-2024
[jdk17u-fix-request] Approval Request from Aleksey Shipilëv This reverts the patch that caused recently identified regression. Clean git revert on jdk17u-dev commit works without problems. GHA will sanity-check it.
05-01-2024
A pull request was submitted for review. URL: https://git.openjdk.org/jdk17u-dev/pull/2103 Date: 2024-01-05 15:54:28 +0000
05-01-2024
A pull request was submitted for review. URL: https://git.openjdk.org/jdk22/pull/33 Date: 2024-01-05 15:50:39 +0000
05-01-2024
Changeset: ed9f3243 Author: Tobias Hartmann <thartmann@openjdk.org> Date: 2024-01-05 15:40:32 +0000 URL: https://git.openjdk.org/jdk/commit/ed9f3243f04718a50bbdc589437872f7215c0e08
05-01-2024
ILW = SIGSEGV in compiled code because implicit null check is registered for the wrong instruction (regression), cvt instructions on x86 with UseAVX >= 1; easy to reproduce, -XX:UseAVX=0 -XX:-ImplicitNullChecks = HHM = P1
05-01-2024
A pull request was submitted for review. URL: https://git.openjdk.org/jdk/pull/17279 Date: 2024-01-05 13:41:51 +0000
05-01-2024
I think this is rather critical and a potential showstopper for JDK 17.0.11, 21.0.2 and 22. I'll backout JDK-8318562.
05-01-2024
I was able to extract a simple test: java -XX:CompileCommand=quiet -XX:CompileCommand=compileonly,Test::test -XX:CompileCommand=print,Test::setCurve -XX:-TieredCompilation -Xbatch Test.java # # A fatal error has been detected by the Java Runtime Environment: # # SIGSEGV (0xb) at pc=0x00007f3da8dce144, pid=3855132, tid=3855133 # # JRE version: Java(TM) SE Runtime Environment (23.0+4) (fastdebug build 23-ea+4-173) # Java VM: Java HotSpot(TM) 64-Bit Server VM (fastdebug 23-ea+4-173, mixed mode, sharing, compressed oops, compressed class ptrs, g1 gc, linux-amd64) # Problematic frame: # J 84 c2 Test.test(LTest;)D (5 bytes) @ 0x00007f3da8dce144 [0x00007f3da8dce120+0x0000000000000024] I narrowed it down to JDK-8318562 in jdk-22+25-1954. Looks like that change broke implicit null checks. Before: # {method} {0x00007f1b010683e0} 'test' '(LTest;)D' in 'Test' # parm0: rsi:rsi = 'Test' # [sp+0x20] (sp of caller) [...] 0x00007f1b29184e3a: cvtss2sd 0xc(%rsi),%xmm0 ; implicit exception: dispatches to 0x00007f1b29184e52 ;*f2d {reexecute=0 rethrow=0 return_oop=0} ; - Test::get@4 (line 35) ; - Test::test@1 (line 39) After JDK-8318562: # {method} {0x00007ffb35060378} 'test' '(LTest;)D' in 'Test' # parm0: rsi:rsi = 'Test' # [sp+0x20] (sp of caller) [...] 0x00007ffb64a09f40: vxorpd %xmm0,%xmm0,%xmm0 ; implicit exception: dispatches to 0x00007ffb64a09f5c 0x00007ffb64a09f44: vcvtss2sd 0xc(%rsi),%xmm0,%xmm0 ;*f2d {reexecute=0 rethrow=0 return_oop=0} ; - Test::get@4 (line 10) ; - Test::test@1 (line 14) The implicit exception now points to the newly added vxorpd instead of the vcvtss2sd which then SIGSEGVs because rsi is null.
05-01-2024