JDK-8182114 : assert(VM_Version::supports_sse()) failed
  • Type: Bug
  • Component: hotspot
  • Sub-Component: compiler
  • Affected Version: 10
  • Priority: P2
  • Status: Closed
  • Resolution: Fixed
  • Submitted: 2017-06-13
  • Updated: 2018-03-01
  • Resolved: 2017-06-16
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 10
10 b21Fixed
Related Reports
Relates :  
JDK-8181616 - FMA Vectorization on x86
Description
Test:
compiler/c1/Test6855215.java
compiler/c1/Test6579789.java

# A fatal error has been detected by the Java Runtime Environment:
#
#  Internal Error (c:/jprt/T/P1/172511.gctriant/s/hotspot/src/cpu/x86/vm/assembler_x86.cpp:2826), pid=43440, tid=56440
#  Error: assert(VM_Version::supports_sse()) failed
#
# JRE version:  (10.0) (fastdebug build )
# Java VM: Java HotSpot(TM) Server VM (fastdebug 10-internal+0-2017-06-12-172511.gctriant.jdk10-hs, compiled mode, tiered, g1 gc, windows-x86)

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

Current thread (0x00e8b000):  JavaThread "Unknown thread" [_thread_in_vm, id=56440, stack(0x02750000,0x027a0000)]

Stack: [0x02750000,0x027a0000],  sp=0x0279f4dc,  free space=317k
Native frames: (J=compiled Java code, A=aot compiled Java code, j=interpreted, Vv=VM code, C=native code)
V  [jvm.dll+0x8f934b]  VMError::report_and_die+0x47b;;  ?report_and_die@VMError@@SAXHPBD0PADPAVThread@@PAEPAX40HI@Z+0x47b
V  [jvm.dll+0x8f9847]  VMError::report_and_die+0x27;;  ?report_and_die@VMError@@SAXPAVThread@@PBDH11PAD@Z+0x27
V  [jvm.dll+0x3dda58]  report_vm_error+0x48;;  ?report_vm_error@@YAXPBDH00ZZ+0x48
V  [jvm.dll+0x1f90c3]  Assembler::movss+0x43;;  ?movss@Assembler@@IAEXPAVXMMRegisterImpl@@VAddress@@@Z+0x43
V  [jvm.dll+0x8a18e3]  TemplateInterpreterGenerator::generate_math_entry+0x1b3;;  ?generate_math_entry@TemplateInterpreterGenerator@@IAEPAEW4MethodKind@AbstractInterpreter@@@Z+0x1b3
V  [jvm.dll+0x89ada7]  TemplateInterpreterGenerator::generate_all+0xae7;;  ?generate_all@TemplateInterpreterGenerator@@IAEXXZ+0xae7
V  [jvm.dll+0x89a2b9]  TemplateInterpreterGenerator::TemplateInterpreterGenerator+0x29;;  ??0TemplateInterpreterGenerator@@QAE@PAVStubQueue@@@Z+0x29
V  [jvm.dll+0x899ed9]  TemplateInterpreter::initialize+0x99;;  ?initialize@TemplateInterpreter@@SAXXZ+0x99
V  [jvm.dll+0x5406d5]  interpreter_init+0x5;;  ?interpreter_init@@YAXXZ+0x5
V  [jvm.dll+0x8b5ec2]  Threads::create_vm+0x212;;  ?create_vm@Threads@@SAHPAUJavaVMInitArgs@@PA_N@Z+0x212
V  [jvm.dll+0x5bf955]  JNI_CreateJavaVM_inner+0x85;;  ?JNI_CreateJavaVM_inner@@YAHPAPAUJavaVM_@@PAPAXPAX@Z+0x85
V  [jvm.dll+0x5c18bf]  JNI_CreateJavaVM+0x4f;;  _JNI_CreateJavaVM@12+0x4f
C  [java.exe+0x2a45]
C  [java.exe+0x3006]
Comments
The problem is that -XX:UseSSE=0 is used by these tests. I doubt it should be P2 - we don't support hardware where SSE is not available. It is artificial case and and it is only 32-bit. I think a lot of places will break if we switch off SSE because we can't use XMM registers. Most likely the code which breaks is introduced by JDK-8154122: "Intrinsify fused mac operations" which was added in JDK 9: http://hg.openjdk.java.net/jdk10/jdk10/hotspot/rev/ca56c5db7157#l14.2
15-06-2017
Note, 64-bit UseSSE min value is 2 and you will get warning otherwise. The only problem is 32-bit x86 - where we did support SSE == 0 for some time. But we did not test this for long time and it may be rotten now. I surprise that we hit this failure only now when JDK-8154122 was pushed 9 months ago. What was changed. It looks like it is due to this recent change JDK-8181616 which replaced UseSSE >= 2 with supports_avx(): http://hg.openjdk.java.net/jdk10/hs/hotspot/rev/78408191085a#l5.2 http://hg.openjdk.java.net/jdk10/hs/hotspot/rev/78408191085a#l6.7 Based on this the simplest fix is restore UseSSE check: - if (supports_fma()) { + if (supports_fma() && UseSSE >= 2) { // Check UseSSE since code use sse instructions
15-06-2017
if we don't support h/w w/o SSE, shouldn't we prohibit UseSSE==0 and report a JVM init-time error if there is no SSE?
15-06-2017
Hi, could you please look into this issue? If this turns out to be a compiler-related problem, please assign it back. Thank you! Zoltan
14-06-2017
Thank you, Igor. Here is the updated ILW: ILW=crash with failing assert and possible hard crash with product builds, two tests so far, no workaround=HLH=P2 I'll move the bug over to the 'runtime' subcomponent.
14-06-2017
'disable SSE could help (not a real workaround)', I doubt it could help, UseSSE was disabled by -XX:UseSSE=0
14-06-2017
isn't it an interpreter bug?
14-06-2017
Hi Rahul, could please look into this issue? Thank you! Zoltan
14-06-2017
ILW=crash with failing assert and possible hard crash with product builds, two tests so far, disable SSE could help (not a real workaround)=HLH=P2 It would be good to check if the same issue exists in 9 as well.
14-06-2017