JDK-8087128 : C2: Disallow definition split on MachCopySpill nodes
  • Type: Bug
  • Component: hotspot
  • Sub-Component: compiler
  • Affected Version: 8u60,9,10,11,12,13
  • Priority: P2
  • Status: Closed
  • Resolution: Fixed
  • Submitted: 2015-06-10
  • Updated: 2019-10-04
  • Resolved: 2019-02-14
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 JDK 13 Other
11.0.5Fixed 13 b09Fixed openjdk8u232Fixed
Related Reports
Duplicate :  
JDK-8212628 - gc/arguments/TestSerialHeapSizeFlags.java failed with "Agent communication error: java.net.SocketException: Broken pipe (Write failed)"
Duplicate :  
JDK-8204842 - applications/ctw/modules/java_desktop_2.java fails intermittently with assert(!n->is_SpillCopy()) failed
Description
The hs_err head is:
#
# A fatal error has been detected by the Java Runtime Environment:
#
#  Internal Error (/opt/jprt/T/P1/061532.amurillo/s/hotspot/src/share/vm/opto/reg_split.cpp:1176), pid=12680, tid=2742930288
#  assert(!n->is_SpillCopy()) failed: 
#
# JRE version: Java(TM) SE Runtime Environment (8.0_60) (build 1.8.0_60-internal-fastdebug-20150605061532.amurillo.hs25-60-b20-set--b00)
# Java VM: Java HotSpot(TM) Server VM (25.60-b20-fastdebug compiled mode linux-x86 )
# Failed to write core dump. 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:
#   http://bugreport.java.com/bugreport/crash.jsp
#

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

Current thread (0xa39c5000):  JavaThread "C2 CompilerThread0" daemon [_thread_in_native, id=12690, stack(0xa375c000,0xa37dd000)]

Stack: [0xa375c000,0xa37dd000],  sp=0xa37d9c80,  free space=503k
Native frames: (J=compiled Java code, j=interpreted, Vv=VM code, C=native code)
V  [libjvm.so+0xe3ef5b]  VMError::report_and_die()+0x17b
V  [libjvm.so+0x609cd8]  report_vm_error(char const*, int, char const*, char const*)+0x68
V  [libjvm.so+0xcba99f]  PhaseChaitin::Split(unsigned int, ResourceArea*)+0x4c3f
V  [libjvm.so+0x49a6cd]  PhaseChaitin::Register_Allocate()+0x7dd
V  [libjvm.so+0x5871a7]  Compile::Code_Gen()+0x2d7
V  [libjvm.so+0x58a5fd]  Compile::Compile(ciEnv*, C2Compiler*, ciMethod*, int, bool, bool, bool)+0x196d
V  [libjvm.so+0x469f8b]  C2Compiler::compile_method(ciEnv*, ciMethod*, int)+0x30b
V  [libjvm.so+0x598d41]  CompileBroker::invoke_compiler_on_method(CompileTask*)+0xbf1
V  [libjvm.so+0x599d7f]  CompileBroker::compiler_thread_loop()+0x74f
V  [libjvm.so+0xdb274f]  compiler_thread_entry(JavaThread*, Thread*)+0x4f
V  [libjvm.so+0xdc3734]  JavaThread::thread_main_inner()+0x234
V  [libjvm.so+0xdc3b04]  JavaThread::run()+0x314
V  [libjvm.so+0xbf4789]  java_start(Thread*)+0x119
C  [libpthread.so.0+0x6a49]
C  [libc.so.6+0xe2aee]  clone+0x5e


Current CompileTask:
C2: 175651 11341   !b  4       jdk.management.resource.SimpleMeter::request (252 bytes)
Comments
Fix Request (8u) Same rationale as for 11u backport. Patch applies cleanly (with reshufflings) to 8u, passes tier1 tests.
08-08-2019
Fix Request (11u) This fixes a nasty regalloc bug. Patch applies cleanly to 11u, passes tier1, tier2 tests. Risk is low (we plainly ignore the node that was previously just asserted).
27-06-2019
http://cr.openjdk.java.net/~neliasso/8087128/webrev.01/
29-01-2019
Disabling UseFPUForSpilling makes this problem go away.
15-01-2019
I can reproduce this with the latest JDK 13 build (revision 53234) and the attached replay compilation file (replay_pid29859.log). n is a MemToRegSpillCopy: (gdb) call _cfg._blocks._blocks[bidx]._nodes._nodes[insidx]->dump(2) 19 MachProj === 12 [[ 9169 ]] #5 Oop:com/sun/tools/javac/code/Types$MembersClosureCache:NotNull * !jvms: HashMap::getNode @ bci:53 HashMap::get @ bci:6 Types$MembersClosureCache::visitClassType @ bci:55 9169 MemToRegSpillCopy === _ 19 [[ 11503 11173 11505 11175 11508 52 11877 11881 8534 9116 9121 9125 9128 9144 9148 9151 9158 9162 9165 8523 9211 9196 9196 9201 97 ]] Oop:com/sun/tools/javac/code/Types$MembersClosureCache:NotNull * 11881 MemToRegSpillCopy === _ 9169 [[ 11886 12063 11884 11882 ]] Oop:com/sun/tools/javac/code/Types$MembersClosureCache:NotNull * (gdb) call _cfg._blocks._blocks[bidx]._nodes._nodes[insidx]->dump(-2) 11881 MemToRegSpillCopy === _ 9169 [[ 11886 12063 11884 11882 ]] Oop:com/sun/tools/javac/code/Types$MembersClosureCache:NotNull * 11886 MemToRegSpillCopy === _ 11881 [[ 11476 ]] Oop:com/sun/tools/javac/code/Types$MembersClosureCache:NotNull * 12063 RegToMemSpillCopy === _ 11881 [[ 1702 ]] Oop:com/sun/tools/javac/code/Types$MembersClosureCache:NotNull * 11884 MemToRegSpillCopy === _ 11881 [[ 11198 ]] Oop:com/sun/tools/javac/code/Types$MembersClosureCache:NotNull * 11882 MemToRegSpillCopy === _ 11881 [[ 11180 ]] Oop:com/sun/tools/javac/code/Types$MembersClosureCache:NotNull * 11476 PhiLocationDifferToInputLocationSpillCopy === _ 11886 [[ 11173 ]] Oop:com/sun/tools/javac/code/Types$MembersClosureCache:NotNull * 1702 CallStaticJavaDirect === 7282 185 182 16 0 1715 187 9185 12063 9182 0 9184 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 [[ 1703 1701 1718 1719 1753 8317 ]] Static java.util.HashMap$TreeNode::getTreeNode # java/util/HashMap$TreeNode:exact * ( java/util/HashMap$TreeNode:NotNull:exact *, int, java/lang/Object * ) HashMap::getNode @ bci:94 HashMap::get @ bci:6 Types$MembersClosureCache::visitClassType @ bci:55 !jvms: Types$MembersClosureCache::visitClassType @ bci:-1 11198 PhiLocationDifferToInputLocationSpillCopy === _ 11884 [[ 9211 ]] Oop:com/sun/tools/javac/code/Types$MembersClosureCache:NotNull * 11180 PhiLocationDifferToInputLocationSpillCopy === _ 11882 [[ 9196 ]] Oop:com/sun/tools/javac/code/Types$MembersClosureCache:NotNull *
10-01-2019
I'm not able to reproduce this issue (the replay compilation file does not work either). If it shows up again, please link the job.
03-12-2018
making it P2, as it affects tier1 and tier2 testing.
29-11-2018
gc/arguments/TestParallelRefProc.java and gc/arguments/TestSerialHeapSizeFlags.java have been seen to hit the same assert.
29-11-2018
Okay, thanks. Yes, it seems to be a different failure.
25-01-2017
is_high_pressure() uses _was_spilled1, which is affected indirectly by _spilled_once: if (_spilled_once.test(n->_idx)) { lrg._was_spilled1 = 1; But it's entirely possible that the failure I'm seeing is different from yours.
25-01-2017
[~dlong], where do you see a side effect of set_was_spilled() on is_high_pressure()? It only sets _spilled_once and _spilled_twice which is not used by is_high_pressure(). Disabling set_was_spilled() still crashes.
24-01-2017
Able to reproduce on Solaris x86 with JDK 9 b153 and attached replay_pid25664.log: bin/java -XX:+ReplayCompiles -XX:+ReplayIgnoreInitErrors -XX:ReplayDataFile=replay_pid25664.log -XX:MaxRAMFraction=8 -XX:+UnlockExperimentalVMOptions -XX:+EnableJVMCI (Requires CLASSPATH to be set to test classes)
24-01-2017
It was an older build. I had to modify the source code to allow UseFPUForSpilling to be set to false.
20-01-2017
I can reproduce this assert easily on arm64 with -XX:-UseCompressedOops -XX:-UseFPUForSpilling -XX:-TieredCompilation -XX:-ReduceFieldZeroing. The node in question was recently split here, when is_high_pressure() returned false: // COPY UP HERE - WITH DEF - NO CISC SPILL maxlrg = split_USE(MachSpillCopyNode::MemToReg, def,b,n,inpidx,maxlrg,true,false, splits,slidx); and then we did set_was_spilled(n->in(inpidx)); which has the side-effect of making is_high_pressure() now return true. I wonder if that's confusing the logic here: // Check for LRG being up in a register and we are inside a high // pressure area. Spill it down immediately. (defup && is_high_pressure(b,&deflrg,insidx))) ) { which might not expect is_high_pressure() to change? I'm just guessing because I don't understand this code at all.
19-01-2017
Hi Dean, thanks for the information. Unfortunately, I'm also not too familiar with the RA code (that was one of the reasons I deferred this to JDK 10). Which build did you use to reproduce this? Feel free to take this bug. Otherwise, I'll pick it up after ZBB.
19-01-2017
Deferral approved by SQE: no impact on overall product. Extremely rare assert in debug build which wasn't introduced in 9, so, no impact on end user.
27-06-2016
Requesting deferral to 10: This is a very complicated issue in the register allocator that requires a more in depth analysis. The problem also affects JDK 8 and is very intermittent (only showed up twice this year). As far as I know, only debug builds are affected.
24-06-2016
I was finally able to reproduce the issue. We crash while compiling java/util/HashMap::put. Here is some debug information I gathered: n = 5328 MemToRegSpillCopy === _ 3650 [[ 5329 5514 ]] Oop:java/lang/Object * deflrg = 2 [], #?(0) EffDeg: ? Def: N5328 Cost:0.29 Area:0.92 Score:0.063 Oop Spilled Copy Risk dmask = [R10-R9_H,RCX-R14_H] defup = 1 ireg = 4 is_vect = 0 Some more context: 55 MachProj === 33 [[ 3650 ]] #7 Oop:java/lang/Object * !jvms: HashMap::put @ bci:-1 3650 DefinitionSpillCopy === _ 55 [[ 5059 5260 5263 5482 4771 5064 3803 3688 5337 5328 5321 5318 5315 5273 5266 3797 ]] Oop:java/lang/Object * 5328 MemToRegSpillCopy === _ 3650 [[ 5329 5514 ]] Oop:java/lang/Object * 5329 MemToRegSpillCopy === _ 5328 [[ 4865 ]] Oop:java/lang/Object * 5514 RegToMemSpillCopy === _ 5328 [[ 145 ]] Oop:java/lang/Object * 4865 PhiLocationDifferToInputLocationSpillCopy === _ 5329 [[ 3787 ]] Oop:java/lang/Object * 145 CallDynamicJavaDirect === 2700 116 117 54 0 3780 159 0 0 0 3773 3774 3771 5514 148 147 3775 3779 0 0 0 0 0 [[ 146 144 169 346 355 3410 ]] Dynamic java.lang.Object::equals # bool ( java/lang/Object:NotNull *, java/lang/Object * ) HashMap::putVal @ bci:91 HashMap::put @ bci:9 !jvms: HashMap::putVal @ bci:91 HashMap::put @ bci:9 I'm not sure but MemToRegSpillCopy as input to MemToRegSpillCopy looks invalid. Investigating..
03-03-2016
[~adlertz], please only take a quick look. Maybe you can figure out what the issue is and then we will reassign to someone else.
15-06-2015
ILW=Assert in register alloc, several times w/ -XX:+ResourceManagement and -XX:+DeoptimizeALot, none known = HMH=P1 Fix 9 and 8u60
15-06-2015