JDK-8324734 : Relax too-strict assert(VM_Version::supports_evex()) in Assembler::locate_operand()
  • Type: Bug
  • Component: hotspot
  • Sub-Component: runtime
  • Affected Version: 22,23
  • Priority: P3
  • Status: Resolved
  • Resolution: Fixed
  • CPU: x86_64
  • Submitted: 2024-01-25
  • Updated: 2024-02-06
  • Resolved: 2024-01-30
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 23
23 b08Fixed
Related Reports
Relates :  
Description
When running on a machine for which we downgrade to UseAVX=2, the InternalErrorTest will run into the assert:

#  Internal Error (/home/admin/src/openjdk/jdk/src/hotspot/cpu/x86/assembler_x86.cpp:1092), pid=1199167, tid=1199188
#  assert(VM_Version::supports_evex()) failed: shouldn't have EVEX prefix

This happens because memset (which InternalErrorTest ends up calling) *does* use AVX512F instructions, but the decoder doesn't expect it at the SIGBUS site in memset, because we downgrade UseAVX to 2 in vm_version_x86.cpp:

  if (FLAG_IS_DEFAULT(UseAVX)) {
    // Don't use AVX-512 on older Skylakes unless explicitly requested.
    if (use_avx_limit > 2 && is_intel_skylake() && _stepping < 5) {
      FLAG_SET_DEFAULT(UseAVX, 2);
    } else {
      FLAG_SET_DEFAULT(UseAVX, use_avx_limit);
    }
  }

Caused by, or related to JDK-JDK-8320886.

Full stack is:
#
# A fatal error has been detected by the Java Runtime Environment:
#
#  Internal Error (/home/admin/src/openjdk/jdk/src/hotspot/cpu/x86/assembler_x86.cpp:1092), pid=1199167, tid=1199188
#  assert(VM_Version::supports_evex()) failed: shouldn't have EVEX prefix
#
# JRE version: OpenJDK Runtime Environment (23.0) (slowdebug build 23-internal-adhoc.admin.jdk)
# Java VM: OpenJDK 64-Bit Server VM (slowdebug 23-internal-adhoc.admin.jdk, mixed mode, sharing, tiered, compressed oops, compressed class ptrs, serial gc, linux-amd64)
# Problematic frame:
# V  [libjvm.so+0x6a24be]  Assembler::locate_operand(unsigned char*, Assembler::WhichOperand)+0xa02
#
# No core dump will be written. Core dumps have been disabled. To enable core dumping, try "ulimit -c unlimited" before starting Java again
#
# 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: -Dtest.vm.opts=-XX:MaxRAMPercentage=1.38889 -Dtest.boot.jdk=/usr/lib/jvm/java-21-amazon-corretto -Djava.io.tmpdir=/home/admin/src/openjdk/jdk/build/linux-x86_64-server-slowdebug/test-support/jtreg_test_hotspot_jtreg_runtime_Unsafe_InternalErrorTest_java/tmp -XX:+UseSerialGC -XX:+UnlockExperimentalVMOptions -XX:+UseCompressorFullGC -Dtest.tool.vm.opts=-J-XX:MaxRAMPercentage=1.38889 -J-Dtest.boot.jdk=/usr/lib/jvm/java-21-amazon-corretto -J-Djava.io.tmpdir=/home/admin/src/openjdk/jdk/build/linux-x86_64-server-slowdebug/test-support/jtreg_test_hotspot_jtreg_runtime_Unsafe_InternalErrorTest_java/tmp -J-XX:+UseSerialGC -J-XX:+UnlockExperimentalVMOptions -J-XX:+UseCompressorFullGC -Dtest.compiler.opts= -Dtest.java.opts= -Dtest.jdk=/home/admin/src/openjdk/jdk/build/linux-x86_64-server-slowdebug/images/jdk -Dcompile.jdk=/home/admin/src/openjdk/jdk/build/linux-x86_64-server-slowdebug/images/jdk -Dtest.timeout.factor=4.0 -Dtest.nativepath=/home/admin/src/openjdk/jdk/build/linux-x86_64-server-slowdebug/images/test/hotspot/jtreg/native -Dtest.root=/home/admin/src/openjdk/jdk/test/hotspot/jtreg -Dtest.name=runtime/Unsafe/InternalErrorTest.java -Dtest.file=/home/admin/src/openjdk/jdk/test/hotspot/jtreg/runtime/Unsafe/InternalErrorTest.java -Dtest.src=/home/admin/src/openjdk/jdk/test/hotspot/jtreg/runtime/Unsafe -Dtest.src.path=/home/admin/src/openjdk/jdk/test/hotspot/jtreg/runtime/Unsafe:/home/admin/src/openjdk/jdk/test/lib -Dtest.classes=/home/admin/src/openjdk/jdk/build/linux-x86_64-server-slowdebug/test-support/jtreg_test_hotspot_jtreg_runtime_Unsafe_InternalErrorTest_java/classes/0/runtime/Unsafe/InternalErrorTest.d -Dtest.class.path=/home/admin/src/openjdk/jdk/build/linux-x86_64-server-slowdebug/test-support/jtreg_test_hotspot_jtreg_runtime_Unsafe_InternalErrorTest_java/classes/0/runtime/Unsafe/InternalErrorTest.d:/home/admin/src/openjdk/jdk/build/linux-x86_64-server-slowdebug/test-support/jtreg_test_hotspot_jtreg_runtime_Unsafe_InternalErrorTest_java/classes/0/test/lib -Dtest.class.path.prefix=/home/admin/src/openjdk/jdk/build/linux-x86_64-server-slowdebug/test-support/jtreg_test_hotspot_jtreg_runtime_Unsafe_InternalErrorTest_java/classes/0/runtime/Unsafe/InternalErrorTest.d:/home/admin/src/openjdk/jdk/test/hotspot/jtreg/runtime/Unsafe:/home/admin/src/openjdk/jdk/build/linux-x86_64-server-slowdebug/test-support/jtreg_test_hotspot_jtreg_runtime_Unsafe_InternalErrorTest_java/classes/0/test/lib -Dtest.modules=java.base/jdk.internal.misc java.base/java.nio:+open --add-modules=java.base --add-exports=java.base/jdk.internal.misc=ALL-UNNAMED --add-exports=java.base/java.nio=ALL-UNNAMED --add-opens=java.base/java.nio=ALL-UNNAMED -XX:MaxRAMPercentage=1.38889 -Dtest.boot.jdk=/usr/lib/jvm/java-21-amazon-corretto -Djava.io.tmpdir=/home/admin/src/openjdk/jdk/build/linux-x86_64-server-slowdebug/test-support/jtreg_test_hotspot_jtreg_runtime_Unsafe_InternalErrorTest_java/tmp -XX:+UseSerialGC -XX:+UnlockExperimentalVMOptions -XX:+UseCompressorFullGC -Djava.library.path=/home/admin/src/openjdk/jdk/build/linux-x86_64-server-slowdebug/images/test/hotspot/jtreg/native -XX:CompileCommand=exclude,*InternalErrorTest.main -XX:CompileCommand=inline,*.get -XX:CompileCommand=inline,*Unsafe.* -Xbootclasspath/a:. -XX:+UnlockDiagnosticVMOptions -XX:+WhiteBoxAPI com.sun.javatest.regtest.agent.MainWrapper /home/admin/src/openjdk/jdk/build/linux-x86_64-server-slowdebug/test-support/jtreg_test_hotspot_jtreg_runtime_Unsafe_InternalErrorTest_java/runtime/Unsafe/InternalErrorTest.d/main.0.jta
 
Host: ip-172-31-26-233, Intel(R) Xeon(R) Platinum 8124M CPU @ 3.00GHz, 36 cores, 68G, Debian GNU/Linux 12 (bookworm)
Time: Thu Jan 25 18:42:54 2024 UTC elapsed time: 1.737131 seconds (0d 0h 0m 1s)
 
---------------  T H R E A D  ---------------
 
Current thread (0x00007faa9829b0b0):  JavaThread "MainThread"        [_thread_in_vm, id=1199188, stack(0x00007faa9e4e5000,0x00007faa9e5e5000) (1024K)]
 
Stack: [0x00007faa9e4e5000,0x00007faa9e5e5000],  sp=0x00007faa9e5e2060,  free space=1012k
Native frames: (J=compiled Java code, j=interpreted, Vv=VM code, C=native code)
V  [libjvm.so+0x6a24be]  Assembler::locate_operand(unsigned char*, Assembler::WhichOperand)+0xa02  (assembler_x86.cpp:1092)
V  [libjvm.so+0x6a2911]  Assembler::locate_next_instruction(unsigned char*)+0x1d  (assembler_x86.cpp:1243)
V  [libjvm.so+0x1378727]  PosixSignals::pd_hotspot_signal_handler(int, siginfo_t*, ucontext_t*, JavaThread*)+0x31d  (os_linux_x86.cpp:320)
V  [libjvm.so+0x155649a]  JVM_handle_linux_signal+0x429  (signals_posix.cpp:645)
V  [libjvm.so+0x155655b]  javaSignalHandler(int, siginfo_t*, void*)+0x2a  (signals_posix.cpp:668)
C  [libc.so.6+0x3bfd0]
V  [libjvm.so+0x991c11]  Copy::fill_to_bytes(void*, unsigned long, unsigned char)+0x2c  (copy.hpp:278)
V  [libjvm.so+0xa5ced7]  Copy::fill_to_memory_atomic(void*, unsigned long, unsigned char)+0x159  (copy.cpp:255)
V  [libjvm.so+0x16dac7f]  Unsafe_SetMemory0+0xf4  (unsafe.cpp:395)
j  jdk.internal.misc.Unsafe.setMemory0(Ljava/lang/Object;JJB)V+0 java.base@23-internal
j  jdk.internal.misc.Unsafe.setMemory(Ljava/lang/Object;JJB)V+25 java.base@23-internal
j  jdk.internal.misc.ScopedMemoryAccess.setMemoryInternal(Ljdk/internal/foreign/MemorySessionImpl;Ljava/lang/Object;JJB)V+17 java.base@23-internal
j  jdk.internal.misc.ScopedMemoryAccess.setMemory(Ljdk/internal/foreign/MemorySessionImpl;Ljava/lang/Object;JJB)V+8 java.base@23-internal
j  jdk.internal.foreign.AbstractMemorySegmentImpl.fill(B)Ljava/lang/foreign/MemorySegment;+30 java.base@23-internal
j  InternalErrorTest.test(Ljava/nio/MappedByteBuffer;Ljdk/internal/misc/Unsafe;JJI)V+105
j  InternalErrorTest.main([Ljava/lang/String;)V+231
j  java.lang.invoke.LambdaForm$DMH+0x00007faa40002800.invokeStatic(Ljava/lang/Object;Ljava/lang/Object;)V+10 java.base@23-internal
j  java.lang.invoke.LambdaForm$MH+0x00007faa40003c00.invoke(Ljava/lang/Object;Ljava/lang/Object;Ljava/lang/Object;)Ljava/lang/Object;+33 java.base@23-internal
j  java.lang.invoke.Invokers$Holder.invokeExact_MT(Ljava/lang/Object;Ljava/lang/Object;Ljava/lang/Object;Ljava/lang/Object;)Ljava/lang/Object;+20 java.base@23-internal
j  jdk.internal.reflect.DirectMethodHandleAccessor.invokeImpl(Ljava/lang/Object;[Ljava/lang/Object;)Ljava/lang/Object;+55 java.base@23-internal
j  jdk.internal.reflect.DirectMethodHandleAccessor.invoke(Ljava/lang/Object;[Ljava/lang/Object;)Ljava/lang/Object;+23 java.base@23-internal
j  java.lang.reflect.Method.invoke(Ljava/lang/Object;[Ljava/lang/Object;)Ljava/lang/Object;+102 java.base@23-internal
j  com.sun.javatest.regtest.agent.MainWrapper$MainTask.run()V+134
j  java.lang.Thread.runWith(Ljava/lang/Object;Ljava/lang/Runnable;)V+5 java.base@23-internal
j  java.lang.Thread.run()V+19 java.base@23-internal
v  ~StubRoutines::call_stub 0x00007faa87c17d21
V  [libjvm.so+0xe416c8]  JavaCalls::call_helper(JavaValue*, methodHandle const&, JavaCallArguments*, JavaThread*)+0x634  (javaCalls.cpp:415)
V  [libjvm.so+0x1374b00]  os::os_exception_wrapper(void (*)(JavaValue*, methodHandle const&, JavaCallArguments*, JavaThread*), JavaValue*, methodHandle const&, JavaCallArguments*, JavaThread*)+0x36  (os_linux.cpp:4903)
V  [libjvm.so+0xe41091]  JavaCalls::call(JavaValue*, methodHandle const&, JavaCallArguments*, JavaThread*)+0x3d  (javaCalls.cpp:329)
V  [libjvm.so+0xe400ce]  JavaCalls::call_virtual(JavaValue*, Klass*, Symbol*, Symbol*, JavaCallArguments*, JavaThread*)+0x1ba  (javaCalls.cpp:185)
V  [libjvm.so+0xe401d7]  JavaCalls::call_virtual(JavaValue*, Handle, Klass*, Symbol*, Symbol*, JavaThread*)+0x95  (javaCalls.cpp:191)
V  [libjvm.so+0xf83f28]  thread_entry(JavaThread*, JavaThread*)+0x8e  (jvm.cpp:2937)
V  [libjvm.so+0xe5bf74]  JavaThread::thread_main_inner()+0x168  (javaThread.cpp:721)
V  [libjvm.so+0xe5be09]  JavaThread::run()+0x1d7  (javaThread.cpp:706)
V  [libjvm.so+0x1696cc1]  Thread::call_run()+0x1b9  (thread.cpp:221)
V  [libjvm.so+0x136a9b0]  thread_native_entry(Thread*)+0x1cb  (os_linux.cpp:789)
Java frames: (J=compiled Java code, j=interpreted, Vv=VM code)
j  jdk.internal.misc.Unsafe.setMemory0(Ljava/lang/Object;JJB)V+0 java.base@23-internal
Comments
Changeset: f0024f58 Author: Roman Kennke <rkennke@openjdk.org> Date: 2024-01-30 13:26:10 +0000 URL: https://git.openjdk.org/jdk/commit/f0024f585dcc1d8afe5808bf626efd8f514da070
30-01-2024

> Yes, because supports_evex() only reflects HotSpot's own code generation. FWIW, when I fixed JDK-8320886, we were already using the decoder to decode SIGBUS pcs in other non-hotspot-generated code, such as `Copy::conjoint_swap` called by `Unsafe_CopySwapMemory0`, which can end up calling memcpy. So, I think the decoder is intended to work on non-hotspot-generated code as well. As a long term solution, maybe VM_Version could distinguish between CPU features that are supported by the CPU, and features that are enabled. Then, the decoder could check whether evex is supported, while other code could be changed to check whether use of evex is enabled for hotspot's own code gen. (Thanks for picking this up BTW)
26-01-2024

A pull request was submitted for review. URL: https://git.openjdk.org/jdk/pull/17590 Date: 2024-01-26 15:18:39 +0000
26-01-2024

> So, if I understand correctly, `supports_evex()` returns false, even though the CPU actually supports EVEX instructions, they are just not being used for hotspot's own code generation? Yes, that is correct. The code that 'downgrades' to UseAVX=2 has been introduced by JDK-8221092. > It seems like the issue is in the implementation of `supports_evex`, and the new test case added by JDK-8320886 is triggering this. Yes, because supports_evex() only reflects HotSpot's own code generation. The failure happens because of the SIGBUS that the testcase is provocating in memset. > I think as a stop gap solution, the assertion could be removed. Yes I think that should work.
26-01-2024

So, if I understand correctly, `supports_evex()` returns false, even though the CPU actually supports EVEX instructions, they are just not being used for hotspot's own code generation? It seems like the issue is in the implementation of `supports_evex`, and the new test case added by JDK-8320886 is triggering this. I think as a stop gap solution, the assertion could be removed.
26-01-2024