JDK-8202565 : C1 compilation crashes with "assert(is_double_stack() && !is_virtual()) failed: type check"
  • Type: Bug
  • Component: hotspot
  • Sub-Component: compiler
  • Affected Version: 11
  • Priority: P2
  • Status: Resolved
  • Resolution: Fixed
  • Submitted: 2018-05-03
  • Updated: 2025-06-11
  • Resolved: 2018-05-07
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 b13Fixed
Related Reports
Relates :  
JDK-8201543 - Modularize C1 GC barriers
Relates :  
JDK-8359235 - C1 compilation fails with "assert(is_single_stack() && !is_virtual()) failed: type check"
Description
Test: vmTestbase/nsk/jvmti/RedefineClasses/StressRedefine/TestDescription.java

#  Internal Error (t:\\workspace\\open\\src\\hotspot\\share\\c1/c1_LIR.hpp:412), pid=4576, tid=7288
#  assert(is_double_stack() && !is_virtual()) failed: type check
Comments
URL: http://hg.openjdk.java.net/jdk/jdk/rev/e81481fea884 User: thartmann Date: 2018-05-07 06:57:03 +0000
07-05-2018
Thanks Eric, I'll send the patch out for review.
04-05-2018
[~thartmann] Right, your analysis is correct. In my refactoring I tried to retain a previous C1 optimization where the address is eagerly resolved to register (lea) before the store, when it is known that the post-write barrier will want the effective address in register anyway. But your analysis is correct that the post-write barrier only needs it to be resolved when using precise marking. So your fix makes sense to me.
03-05-2018
I've attached the relevant block of the LIR. The problem is the following instruction: 2148 move [stack:19|L] [rsirsi|J] because moving a T_OBJECT from the stack to a T_LONG double-register is not allowed. This code is part of the G1 post barrier for an object field store (stack:19 is the base oop). We do support such a special case for reg2reg though (the comment is a bit misleading): http://hg.openjdk.java.net/jdk/jdk/file/fc778e86381f/src/hotspot/cpu/x86/c1_LIRAssembler_x86.cpp#l850 I've also attached the LIR for a run without the JDK-8201543 changes (LIR_baseline.log). In this case, the base oop is in rsi so we just do a reg2reg move: 2142 move [rsi|L] [raxrax|J] A straight forward fix would be to add a special case for stack2reg as well but I was wondering why this only shows up with the fix for JDK-8201543. Turns out that we now eagerly resolve the address into a register in the cases were it is used by the barrier: http://hg.openjdk.java.net/jdk/jdk/file/fc778e86381f/src/hotspot/share/gc/shared/c1/modRefBarrierSetC1.cpp#l84 In the failing case (LIR.log), we use r8 to store this address 2132 leal [Base:[rsi|L] Disp: 44|L] [r8r8|J] and as a result, register pressure is higher and we have to spill rsi move [rsi|L] [stack:19|L] and need to reload it from the stack -> crash. In this case the post barrier does not even use the address but only the base oop. ModRefBarrierSetC1::store_at_resolved() only passes resolved_addr() to the barrier if the store is precise (on_array || on_anonymous), which is not the case here. The following change to ModRefBarrierSetC1::resolve_address() solves this instance of the problem: diff -r 7379e6f906ae src/hotspot/share/gc/shared/c1/modRefBarrierSetC1.cpp --- a/src/hotspot/share/gc/shared/c1/modRefBarrierSetC1.cpp Thu May 03 07:35:17 2018 +0200 +++ b/src/hotspot/share/gc/shared/c1/modRefBarrierSetC1.cpp Thu May 03 17:27:19 2018 +0200 @@ -87,6 +87,9 @@ DecoratorSet decorators = access.decorators(); bool needs_patching = (decorators & C1_NEEDS_PATCHING) != 0; bool is_write = (decorators & C1_WRITE_ACCESS) != 0; - resolve_in_register |= !needs_patching && is_write && access.is_oop(); + bool on_array = (decorators & IN_HEAP_ARRAY) != 0; + bool on_anonymous = (decorators & ON_UNKNOWN_OOP_REF) != 0; + bool precise = on_array || on_anonymous; + resolve_in_register |= !needs_patching && is_write && access.is_oop() && precise; return BarrierSetC1::resolve_address(access, resolve_in_register); } But I wonder why this code was added at all? [~eosterlund], [~rbackman], could you please have a look?
03-05-2018
ILW = Crash during compilation with C1, intermittent but easy to reproduce with replay compilation, disable compilation or use other GC than G1 = HMM = P2
03-05-2018
I'm able to reproduce this with the attached replay compilation file. I've tracked the bug back to build jdk-jdk.8047 which only contains two changesets (JDK-8201543 and JDK-8201367) where the latter is a pure C2 change. Therefore, the bug was introduced by JDK-8201543. I'll investigate.
03-05-2018
There were no C1 changes in the nightly build for this failure (build 43), but there were changes in build 42: JDK-8200167 and JDK-8202399. However, based on the stack trace above I can't see any connection with those two bugs.
03-05-2018
# # A fatal error has been detected by the Java Runtime Environment: # # Internal Error (t:\workspace\open\src\hotspot\share\c1/c1_LIR.hpp:412), pid=4576, tid=7288 # assert(is_double_stack() && !is_virtual()) failed: type check # # JRE version: Java(TM) SE Runtime Environment (11.0) (fastdebug build 11-internal+0-2018-05-02-0519059.mach5noticeswwgrp.source) # Java VM: Java HotSpot(TM) 64-Bit Server VM (fastdebug 11-internal+0-2018-05-02-0519059.mach5noticeswwgrp.source, mixed mode, tiered, compressed oops, g1 gc, windows-amd64) # Core dump will be written. Default location: T:\testoutput\jtreg\JTwork\scratch\2\hs_err_pid4576.mdmp # # If you would like to submit a bug report, please visit: # http://bugreport.java.com/bugreport/crash.jsp # --------------- S U M M A R Y ------------ Command Line: -XX:MaxRAMPercentage=8 -Djava.library.path=C:\ade\mesos\work_dir\jib-master\install\2018-05-02-0519059.mach5_notices_ww_grp.source\windows-x64-debug.test\hotspot\jtreg\native -agentlib:stressRedefine nsk.jvmti.RedefineClasses.StressRedefine ./bin Host: sca00meo, Intel(R) Xeon(R) CPU E5-2690 0 @ 2.90GHz, 6 cores, 30G, Windows Server 2012 R2 , 64 bit Build 9600 (6.3.9600.17415) Time: Wed May 02 07:07:41 2018 ric elapsed time: 35 seconds (0d 0h 0m 35s) --------------- T H R E A D --------------- Current thread (0x000000c478fbb000): JavaThread "C1 CompilerThread0" daemon [_thread_in_native, id=7288, stack(0x000000c47a130000,0x000000c47a230000)] Current CompileTask: C1: 35337 5197 % ! 3 java.util.concurrent.ConcurrentHashMap::transfer @ 372 (828 bytes) Stack: [0x000000c47a130000,0x000000c47a230000] Native frames: (J=compiled Java code, j=interpreted, Vv=VM code, C=native code) V [jvm.dll+0xab24c0] os::platform_print_native_stack+0xf0 (os_windows_x86.cpp:373) V [jvm.dll+0xc7738c] VMError::report+0xe0c (vmerror.cpp:691) V [jvm.dll+0xc787d7] VMError::report_and_die+0x5d7 (vmerror.cpp:1403) V [jvm.dll+0xc78e24] VMError::report_and_die+0x64 (vmerror.cpp:1237) V [jvm.dll+0x52c6ce] report_vm_error+0x7e (debug.cpp:233) V [jvm.dll+0x35942b] LIR_OprDesc::double_stack_ix+0x8b (c1_lir.hpp:412) V [jvm.dll+0x373df0] LIR_Assembler::stack2reg+0x290 (c1_lirassembler_x86.cpp:1111) V [jvm.dll+0x3617c3] LIR_Assembler::emit_op1+0x173 (c1_lirassembler.cpp:508) V [jvm.dll+0x361319] LIR_Assembler::emit_lir_list+0x1a9 (c1_lirassembler.cpp:293) V [jvm.dll+0x360b8e] LIR_Assembler::emit_block+0x1de (c1_lirassembler.cpp:259) V [jvm.dll+0x360e07] LIR_Assembler::emit_code+0x97 (c1_lirassembler.cpp:217) V [jvm.dll+0x328693] Compilation::emit_code_body+0x133 (c1_compilation.cpp:353) V [jvm.dll+0x328341] Compilation::compile_java_method+0x271 (c1_compilation.cpp:404) V [jvm.dll+0x32847e] Compilation::compile_method+0xde (c1_compilation.cpp:464) V [jvm.dll+0x3271a8] Compilation::Compilation+0x1d8 (c1_compilation.cpp:585) V [jvm.dll+0x329c17] Compiler::compile_method+0xd7 (c1_compiler.cpp:250) V [jvm.dll+0x4e35a8] CompileBroker::invoke_compiler_on_method+0x638 (compilebroker.cpp:2110) V [jvm.dll+0x4e1811] CompileBroker::compiler_thread_loop+0x301 (compilebroker.cpp:1812) V [jvm.dll+0xc26d41] JavaThread::thread_main_inner+0x211 (thread.cpp:1801) V [jvm.dll+0xc25b59] JavaThread::run+0x259 (thread.cpp:1783) V [jvm.dll+0xab134c] thread_native_entry+0x11c (os_windows.cpp:424) C [msvcr120.dll+0x24f7f] C [msvcr120.dll+0x25126] C [KERNEL32.DLL+0x13d2] C [ntdll.dll+0x154f4]
03-05-2018