JDK-8014959 : assert(Compile::current()->live_nodes() < (uint)MaxNodeLimit) failed: Live Node limit exceeded limit
  • Type: Bug
  • Component: hotspot
  • Sub-Component: compiler
  • Affected Version: hs25
  • Priority: P2
  • Status: Closed
  • Resolution: Fixed
  • Submitted: 2013-05-21
  • Updated: 2015-11-19
  • Resolved: 2013-06-12
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 8 Other
8Fixed hs25Fixed
Related Reports
Relates :  
JDK-6934604 - enable parts of EliminateAutoBox by default
Relates :  
JDK-8143321 - Reduce the C2 compiler's memory usage
Relates :  
JDK-8015837 - Nashorn crashes with tiered on x86 when running v8 benchmark
Relates :  
JDK-8011858 - Use Compile::live_nodes() instead of Compile::unique() in appropriate places
Description
during PIT of hs25-b33 for jdk8-b91 vm/mlvm/meth/stress/jdi/breakpointInCompiledCode trigger assert:

;; Using jvm: "/export/local/aurora/sandbox/sca/vmsqe/jdk/pit/2013-05-17-160126.amurillo.hs25-b33-snapshot/fastdebug/linux-i586/jre/lib/i386/server/libjvm.so"
#
# A fatal error has been detected by the Java Runtime Environment:
#
#  Internal Error (/opt/jprt/T/P1/160126.amurillo/s/src/share/vm/opto/node.cpp:71), pid=26937, tid=2972064624
#  assert(Compile::current()->live_nodes() < (uint)MaxNodeLimit) failed: Live Node limit exceeded limit
#
# JRE version: Java(TM) SE Runtime Environment (8.0-b89) (build 1.8.0-ea-fastdebug-b89)
# Java VM: Java HotSpot(TM) Server VM (25.0-b33-internal-201305171601.amurillo.hs25-b33-snapshot-fastdebug mixed 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.sun.com/bugreport/crash.jsp
#

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

Current thread (0x096b1c00):  JavaThread "C2 CompilerThread1" daemon [_thread_in_native, id=26956, stack(0xb11e1000,0xb1262000)]

Stack: [0xb11e1000,0xb1262000],  sp=0xb125f3c0,  free space=504k
Native frames: (J=compiled Java code, j=interpreted, Vv=VM code, C=native code)
V  [libjvm.so+0xc32b1e]  VMError::report_and_die()+0x1ae;;  VMError::report_and_die()+0x1ae
V  [libjvm.so+0x5790a8]  report_vm_error(char const*, int, char const*, char const*)+0x68;;  report_vm_error(char const*, int, char const*, char const*)+0x68
V  [libjvm.so+0x9f435c]  Node::verify_construction()+0x17c;;  Node::verify_construction()+0x17c
V  [libjvm.so+0x9fb28b]  Node::clone() const+0x21b;;  Node::clone() const+0x21b
V  [libjvm.so+0x96d1d4]  Matcher::xform(Node*, int)+0x584;;  Matcher::xform(Node*, int)+0x584
V  [libjvm.so+0x96e6d7]  Matcher::match()+0xc07;;  Matcher::match()+0xc07
V  [libjvm.so+0x507e00]  Compile::Code_Gen()+0x140;;  Compile::Code_Gen()+0x140
V  [libjvm.so+0x50c908]  Compile::Compile(ciEnv*, C2Compiler*, ciMethod*, int, bool, bool, bool)+0x1608;;  Compile::Compile(ciEnv*, C2Compiler*, ciMethod*, int, bool, bool, bool)+0x1608
V  [libjvm.so+0x4078a3]  C2Compiler::compile_method(ciEnv*, ciMethod*, int)+0x2e3;;  C2Compiler::compile_method(ciEnv*, ciMethod*, int)+0x2e3
V  [libjvm.so+0x515c6b]  CompileBroker::invoke_compiler_on_method(CompileTask*)+0xa6b;;  CompileBroker::invoke_compiler_on_method(CompileTask*)+0xa6b
V  [libjvm.so+0x516c65]  CompileBroker::compiler_thread_loop()+0x805;;  CompileBroker::compiler_thread_loop()+0x805
V  [libjvm.so+0xbbb21f]  compiler_thread_entry(JavaThread*, Thread*)+0x4f;;  compiler_thread_entry(JavaThread*, Thread*)+0x4f
V  [libjvm.so+0xbcaec9]  JavaThread::thread_main_inner()+0x1b9;;  JavaThread::thread_main_inner()+0x1b9
V  [libjvm.so+0xbcb1be]  JavaThread::run()+0x24e;;  JavaThread::run()+0x24e
V  [libjvm.so+0xa2c9d9]  java_start(Thread*)+0x119;;  java_start(Thread*)+0x119
C  [libpthread.so.0+0x5e72]  start_thread+0xd2
Comments
RULE vm/mlvm/meth/stress/jdi/breakpointInCompiledCode Crash Internal Error ...node.cpp...assert..
25-10-2013
David copy this suggestion to https://jbs.oracle.com/bugs/browse/INTJDK-7604173
06-06-2013
I recommend a change to the test. It appears that the number of steps required is about 22 times the methodhandle wrapping depth. Therefore, if the number of steps is 9000, then the wrapping depth (in MHTransformationGen) should not exceed 400. Right now, it is random between 0 and 999 (random nextInt(1000)). I think it might make more sense for this to be something like 250 + nextInt(100). There are also fixes to the compiler to avoid the crash, but even without crashes the test will spuriously fail unless the wrapping depth is limited or the number of steps are increased to about 25000. More steps probably requires more timeout. There's a third problem, which is whether the compiler is making appropriate choices about recompilation in the presence of debugging operations.
06-06-2013
The test itself is not well-formed. I instrumented the test to get a feeling for how many layers were wrapped around mhTarget and how much stepping was necessary to reach it. The important variables are the "mh wrapping depth", 336 in the first run, and the number of steps and amount of time needed to reach mhTarget. Here, that was 7807 steps, and the limit specified in the test (but not this run) was 9000. mh wrapping depth can be as much as 999. A second run with depth=675 resulted in a compiler crash, despite changes to the compiler to (allegedly) prevent this. binder> main=vm.mlvm.share.jdi.MHDebuggee "-stressTime" "60" "-verbose" "-trace.level=2" "-waittime=5" "-debugee.vmkind=java" "-transport.address=dynamic" "-debugger.debuggeeClass" "vm.mlvm.share.jdi.MHDebuggee" "-debugger.breakpoints" "invokeMH:S15000,invokePlain:S9000,~mhTarget,~plainTarget,stop" "-debuggee.iterations" "20000" "-debugee.vmkeys=-server -Xmixed -XX:NodeLimitFudgeFactor=1500 -XX:MaxNodeLimit=75000" "-pipe.port=53702" binder> home=/Users/dr2chase/work/jdk8tl-full/build/macosx-x86_64-normal-server-fastdebug/images/j2sdk-image/jre binder> Launching debugee binder> Waiting for VM initialized Initial VMStartEvent received: VMStartEvent in thread main ### TRACE 2: Requesting ClassPrepareEvent for [vm.mlvm.share.jdi.MHDebuggee] ### TRACE 2: Setting breakpoints for class [class vm.mlvm.share.jdi.MHDebuggee (loaded by instance of sun.misc.Launcher$AppClassLoader(id=96))] ### TRACE 2: Breakpoint request for [invokeMH]: breakpoint request vm.mlvm.share.jpda.SDE_MHDebuggeeBase:61 (enabled) ### TRACE 2: Breakpoint request for [invokePlain]: breakpoint request vm.mlvm.share.jpda.SDE_MHDebuggeeBase:42 (enabled) ### TRACE 2: Implicit breakpoint [mhTarget:0] ### TRACE 2: Implicit breakpoint [plainTarget:0] ### TRACE 2: Breakpoint request for [stop]: breakpoint request vm.mlvm.share.jpda.SDE_MHDebuggeeBase:68 (enabled) debugee.stdout> ### TRACE 1: RNG seed = 350695651723783174 (0x4ddebd651452c06) debugee.stdout> ### TRACE 2: MH Wrapping depth: 336 debugee.stdout> ### TRACE 2: Warming up (20000 iterations) debugee.stdout> ### TRACE 2: Starting main test ### TRACE 2: Execution hit our breakpoint: [invokeMH:0] on step 2 ### TRACE 2: Execution hit our breakpoint: [mhTarget:0] on step 7806 debugee.stdout> ### TRACE 2: Passing mhTarget ### TRACE 2: Execution hit our breakpoint: [invokePlain:0] on step 9383 ### TRACE 2: Execution hit our breakpoint: [plainTarget:0] on step 9384 debugee.stdout> ### TRACE 2: Passing plainTarget ### TRACE 2: Execution hit our breakpoint: [stop:0] on step 10343 ### TRACE 2: All breakpoints are hit. Terminating. ### TRACE 1: Breakpoint for method invokeMH was hit 1 times. OK. ### TRACE 1: Breakpoint for method invokePlain was hit 1 times. OK. ### TRACE 1: Breakpoint for method mhTarget was hit 1 times. OK. ### TRACE 1: Breakpoint for method plainTarget was hit 1 times. OK. ### TRACE 1: Breakpoint for method stop was hit 1 times. OK. debugee.stdout> ### TRACE 2: Passing stop debugee.stdout> ### TRACE 2: MH target invoked = 20000 debugee.stdout> MH invoked = 1 debugee.stdout> Plain target invoked = 20000 debugee.stdout> Plain invoked = 1 debugee.stdout> ### TRACE 2: The test took 115533 ms debugee.stdout> ### TRACE 1: DEBUGGEE PASSED ### TRACE 2: The test took 127501 ms ### TRACE 1: TEST PASSED
06-06-2013
It appears to work if -trace-level=4 is specified on the outer command line (not debuggee-specific) after -verbose.
06-06-2013
A summary of what this test is trying to do: it wants to set two breakpoints, and for each of the two breakpoints, it steps forward many times (current default is 9000). One of the two breakpoints is set at the outside of a large randomly generated pile of lambdas all surrounding mhTarget. The forward stepping goes in, lambda by lambda, till it reaches mhTarget (or not, in which case it fails). There are three failure modes. One is when the node limit is exceeded and the compiler crashes; the second is when the number of steps is insufficient and the target is not reached, the third is when a timeout limit is reached. Tinkering with the test run, I see that I can make it succeed more often by increasing the stressTime (I think that is the timeout parameter) and the number of steps forward. The SQE test needs a little work. One problem that it has is that the debuggee has a lot of optional output dependent on TraceLevel, however my attempt to set this in the debuggee led to an unexplained crash (that is, there was an exception or error message from the debuggee, but it was not supplied to me). For example, MHTransformationGen calls Env.traceDebug, but somehow the setting of trace.level is not allowed. A second problem is that the directory/package structures for the source code do not match; some of the source directories are wrongly capitalized, and there are cases where package names ARE capitalized, contrary to Java style.
06-06-2013
David, I have filed INTJDK-7604173 according to your comment.
06-06-2013
Or after Optimize phase use new Compile value C->_node_limit scaled based on Ideal graph live_nodes value instead of using MaxNodeLimit in the assert.
30-05-2013
We need to add node limit check into Matcher() phase and bailout compilation as we do in Optimize() phase.
30-05-2013
Huge graph from compiled lambda method: java.lang.invoke.LambdaForm$MH/4092174::collect VM hit assert in Matcher when it tries to clone all constant nodes referenced in debug info: Current function is Matcher::xform 1067 m = m->clone(); The problem is the graph has a lot of uncommon trap nodes with a lot of debuginfo constant edges due to deep inlining for lambda: [t@18 l@18]: print m->dump() debugee.stdout> o7735 ConI === o0 [[o62373 ��� 74778 ]] #int:100 [t@18 l@18]: print m->outcnt() m->outcnt() = 5194U [t@18 l@18]: print n->req() n->req() = 729U [t@18 l@18]: print n->dump() 74778 CallStaticJavaDirect === o16671 o15238 o15239 o8 o9 o8297 ... o25 [[ 74779 ]] Static wrapper for: uncommon_trap(reason='null_check' action='make_not_entrant') # void ( int ) C=0.000100 ValueConversions::unboxCharacter @ bci:1 754666084::invokeStatic_LI_I @ bci:11 1568059495::reinvoke @ bci:22 2014866032::convert @ bci:40 1209669119::spread @ bci:109 1684015092::collect @ bci:29 1896294051::convert @ bci:66 345281752::collect @ bci:33 1293618474::collect @ bci:45 1205555397::collect @ bci:38 278934944::collect @ bci:30 1859039536::collect @ bci:32 897074030::collect @ bci:28 786041152::spread @ bci:10 246550802::collect @ bci:18 1134612201::collect @ bci:5 1884122755::collect @ bci:5 394721749::collect @ bci:5 282828951::collect @ bci:5 1075738627::collect @ bci:5 1160003871::collect @ bci:21 22069592::collect @ bci:21 1414147750::collect @ bci:21 1858609436::collect @ bci:19 633075331::convert @ bci:17 1682463303::spread @ bci:40 428910174::collect @ bci:20 2015781843::convert @ bci:20 1113619023::collect @ bci:35 1337344609::convert @ bci:94 415186196::spread @ bci:145 911312317::collect @ bci:33 2114874018::convert @ bci:116 175408781::collect @ bci:24 963522361::collect @ bci:12 770189387::collect @ bci:12 949057310::collect @ bci:25 586084331::collect @ bci:25 712025048::collect @ bci:24 532854629::collect @ bci:24 1131645570::collect @ bci:25 1946403944::convert @ bci:33 1372082959::spread @ bci:57 334203599::collect @ bci:23 1413246829::convert @ bci:33 490150701::collect @ bci:21 1316061703::collect @ bci:21 682376643::collect @ bci:31 603856241::collect @ bci:43 1956710488::collect @ bci:43 149047107::collect @ bci:42 212921632::collect @ bci:43 2050019814::collect @ bci:62 1429880200::collect @ bci:40 1693847660::collect @ bci:40 1136497418::collect @ bci:56 1053631449::collect @ bci:50 2092769598::collect @ bci:33 1122805102::collect @ bci:36 110431793::collect @ bci:35 1181869371::collect @ bci:34 140799417::collect @ bci:34 1250391581::collect @ bci:36 1773206895::collect @ bci:33 1177377518::collect @ bci:36 1780132728::convert @ bci:122 1957502751::spread @ bci:145 1226622409::collect @ bci:33 455538610::convert @ bci:107 242355057::collect @ bci:26 292917034::collect @ bci:40 1629911510::collect @ bci:26 274773041::collect @ bci:26 1630521067::collect @ bci:26 246399377::collect @ bci:62 1320677379::convert @ bci:61 142555199::spread @ bci:74 1629604310::collect @ bci:25 249155636::convert @ bci:61 1990451863::collect @ bci:26 1665404403::collect @ bci:25 171497379::collect @ bci:25 439904756::convert @ bci:61 2011986105::spread @ bci:74 511473681::collect @ bci:25 2050835901::convert @ bci:61 99451533::collect @ bci:28 924477420::collect @ bci:22 331510866::collect @ bci:27 317986356::collect @ bci:14 2070529722::collect @ bci:37 1154002927::collect @ bci:26 1227074340::collect @ bci:16 1728790703::convert @ bci:16 19717364::spread @ bci:25 632249781::collect @ bci:19 1543237999::convert @ bci:24 !jvms: ValueConversions::unboxCharacter @ bci:1 754666084::invokeStatic_LI_I @ bci:11 1568059495::reinvoke @ bci:22 2014866032::convert @ bci:40 1209669119::spread @ bci:109 1684015092::collect @ bci:29 1896294051::convert @ bci:66 345281752::collect @ bci:33 1293618474::collect @ bci:45 1205555397::collect @ bci:38 278934944::collect @ bci:30 1859039536::collect @ bci:32 897074030::collect @ bci:28 786041152::spread @ bci:10 246550802::collect @ bci:18 1134612201::collect @ bci:5 1884122755::collect @ bci:5 394721749::collect @ bci:5 282828951::collect @ bci:5 1075738627::collect @ bci:5 1160003871::collect @ bci:21 22069592::collect @ bci:21 1414147750::collect @ bci:21 1858609436::collect @ bci:19 633075331::convert @ bci:17 1682463303::spread @ bci:40 428910174::collect @ bci:20 2015781843::convert @ bci:20 1113619023::collect @ bci:35 1337344609::convert @ bci:94 415186196::spread @ bci:145 911312317::collect @ bci:33 2114874018::convert @ bci:116 175408781::collect @ bci:24 963522361::collect @ bci:12 770189387::collect @ bci:12 949057310::collect @ bci:25 586084331::collect @ bci:25 712025048::collect @ bci:24 532854629::collect @ bci:24 1131645570::collect @ bci:25 1946403944::convert @ bci:33 1372082959::spread @ bci:57 334203599::collect @ bci:23 1413246829::convert @ bci:33 490150701::collect @ bci:21 1316061703::collect @ bci:21 682376643::collect @ bci:31 603856241::collect @ bci:43 1956710488::collect @ bci:43 149047107::collect @ bci:42 212921632::collect @ bci:43 2050019814::collect @ bci:62 1429880200::collect @ bci:40 1693847660::collect @ bci:40 1136497418::collect @ bci:56 1053631449::collect @ bci:50 2092769598::collect @ bci:33 1122805102::collect @ bci:36 110431793::collect @ bci:35 1181869371::collect @ bci:34 140799417::collect @ bci:34 1250391581::collect @ bci:36 1773206895::collect @ bci:33 1177377518::collect @ bci:36 1780132728::convert @ bci:122 1957502751::spread @ bci:145 1226622409::collect @ bci:33 455538610::convert @ bci:107 242355057::collect @ bci:26 292917034::collect @ bci:40 1629911510::collect @ bci:26 274773041::collect @ bci:26 1630521067::collect @ bci:26 246399377::collect @ bci:62 1320677379::convert @ bci:61 142555199::spread @ bci:74 1629604310::collect @ bci:25 249155636::convert @ bci:61 1990451863::collect @ bci:26 1665404403::collect @ bci:25 171497379::collect @ bci:25 439904756::convert @ bci:61 2011986105::spread @ bci:74 511473681::collect @ bci:25 2050835901::convert @ bci:61 99451533::collect @ bci:28 924477420::collect @ bci:22 331510866::collect @ bci:27 317986356::collect @ bci:14 2070529722::collect @ bci:37 1154002927::collect @ bci:26 1227074340::collect @ bci:16 1728790703::convert @ bci:16 19717364::spread @ bci:25 632249781::collect @ bci:19 1543237999::convert @ bci:24
30-05-2013
This bug is not especially repeatable; in a Linux VM I did not see a crash after ten runs of the test, though I did see some of the breakpoint failure that this test is intended to check for. I will give it 100 runs just for grins, and otherwise will go eyeball the compiler source code. Ah, but without fastdebug, no assert, hence no crash. Try again.
29-05-2013
The assert was added as part of changes for 6934604 because if graph is broken C2 may spin almost infinitely in Ideal graph transformation. I surprise in this bug case we did not hit assert during Optimize phase but hit it in Matcher which should create less mach nodes than ideal nodes.
21-05-2013