JDK-8239852 : java/util/concurrent tests fail with -XX:+VerifyGraphEdges: assert(!VerifyGraphEdges) failed: verification should have failed
  • Type: Bug
  • Component: hotspot
  • Sub-Component: compiler
  • Affected Version: 8,11,15
  • Priority: P3
  • Status: Resolved
  • Resolution: Fixed
  • Submitted: 2020-02-24
  • Updated: 2020-06-09
  • Resolved: 2020-02-28
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 JDK 14 JDK 15 Other
11.0.8-oracleFixed 13.0.4Fixed 14.0.2Fixed 15 b13Fixed openjdk8u262Fixed
Related Reports
Blocks :  
JDK-8167300 - Scheduling failures during gcm should be fatal
Duplicate :  
JDK-8239850 - Shenandoah: VerifyGraphEdges verification failed in PhaseCFG::global_code_motion()
Relates :  
JDK-8239850 - Shenandoah: VerifyGraphEdges verification failed in PhaseCFG::global_code_motion()
Description
Running tier1 with +VerifyGraphEdges reveals a few failures. This seems to happen across all GC configurations. Most (all?) failures are concentrated in java/util/concurrent tests.

$ CONF=linux-x86_64-server-fastdebug make images run-test TEST=java/util/concurrent/ TEST_VM_OPTS="-XX:+VerifyGraphEdges"

==============================
Test summary
==============================
   TEST                                              TOTAL  PASS  FAIL ERROR   
>> jtreg:test/jdk/java/util/concurrent                 108   102     1     5 <<
==============================

Example hs_err excerpt:

#  Internal Error (/home/shade/trunks/jdk-jdk/src/hotspot/share/opto/gcm.cpp:1443), pid=13423, tid=13443
#  assert(!VerifyGraphEdges) failed: verification should have failed
#
# Problematic frame:
# V  [libjvm.so+0xb23f3e]  PhaseCFG::global_code_motion()+0x3de

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

Current thread (0x00007fb080458000):  JavaThread "C2 CompilerThread0" daemon [_thread_in_native, id=13443, stack(0x00007fb06010a000,0x00007fb06020b000)]


Current CompileTask:
C2:  33347 1305       4       java.util.concurrent.locks.AbstractQueuedSynchronizer::hasQueuedPredecessors (58 bytes)

Stack: [0x00007fb06010a000,0x00007fb06020b000],  sp=0x00007fb060205df0,  free space=1007k
Native frames: (J=compiled Java code, A=aot compiled Java code, j=interpreted, Vv=VM code, C=native code)
V  [libjvm.so+0xb23f3e]  PhaseCFG::global_code_motion()+0x3de
V  [libjvm.so+0xb268e1]  PhaseCFG::do_global_code_motion()+0x51
V  [libjvm.so+0x85909f]  Compile::Code_Gen()+0x26f
V  [libjvm.so+0x85d502]  Compile::Compile(ciEnv*, C2Compiler*, ciMethod*, int, bool, bool, bool, DirectiveSet*)+0x1342
V  [libjvm.so+0x6d1e50]  C2Compiler::compile_method(ciEnv*, ciMethod*, int, DirectiveSet*)+0x110
V  [libjvm.so+0x869a6b]  CompileBroker::invoke_compiler_on_method(CompileTask*)+0x2db
V  [libjvm.so+0x86aaa8]  CompileBroker::compiler_thread_loop()+0x538
V  [libjvm.so+0x1689d76]  JavaThread::thread_main_inner()+0x206
V  [libjvm.so+0x168eba6]  Thread::call_run()+0xf6
V  [libjvm.so+0x128cc2e]  thread_native_entry(Thread*)+0x10e
Comments
Fix request (13u) Applicable here, too. Patch applies cleanly, tests pass.
09-06-2020
Fix Request (8u) This eliminates false failures that might obscure other bugs. Patch applies cleanly to 8u. I couldn't reproduce the failures on 8 but I see no reason why it wouldn't be affected. Also, the fix is really low risk (removal of an assert). Testing: tier1.
31-03-2020
Fix Request (JDK 14.0.2) The patch removes a too strong assert that might mask other real issues in testing and has already been backported to JDK 11u. The fix is low risk and applies cleanly to JDK 14.0.2. In addition to CI testing through all tiers in JDK 15 and 11u, additional testing will be executed in JDK 14.0.2 before pushing.
06-03-2020
Fix Request (11u) This eliminates false failure that might obscure other bugs. Patch applies cleanly to 11u, affected tests fail intermittently without the patch, pass with it. Patched JDK passes tier{1,2,3} tests.
29-02-2020
The assert in gcm.cpp Christian mentions was added by JDK-8167300. If/when we backport JDK-8167300 to 8u, the +VerifyGraphEdges removal can be / should be done there as well.
28-02-2020
URL: https://hg.openjdk.java.net/jdk/jdk/rev/8def7c4e6800 User: chagedorn Date: 2020-02-28 15:07:05 +0000
28-02-2020
http://cr.openjdk.java.net/~chagedorn/8239852/webrev.00/ Testing: passed all tests in java/util/concurrent with -XX:+VerifyGraphEdges The failing assert is too strong in some cases where the IR is valid but PhaseCFG::schedule_late() bails out at [1] and the recompilation with subsume_loads == false does not bail out anymore. One such case occurs during the compilation of java.util.concurrent.locks.AbstractQueuedLongSynchronizer::hasQueuedPredecessors when running, for example, [2] with -XX:+VerifyGraphEdges. Before calling PhaseCFG::insert_anti_dependences(), LCA and early both point to block A with _dom_depth x for some node. However, the early block is temporarily changed inside insert_anti_dependences() by memory_early_block() to point to an earlier block B with _dom_depth y < x. The LCA is updated to point to block B and is returned. As a result, the assert fails because early->_dom_depth (x) > LCA->_dom_depth (y). The assert can be completely remove since we already have this assert [3] which catches an unschedulable graph of a compilation with subsume_loads == false and there are no other bailouts in PhaseCFG::schedule_late(). [1] http://hg.openjdk.java.net/jdk/jdk/file/61ee15b9a1ac/src/hotspot/share/opto/gcm.cpp#l1349 [2] http://hg.openjdk.java.net/jdk/jdk/file/61ee15b9a1ac/test/jdk/java/util/concurrent/Semaphore/RacingReleases.java [3] http://hg.openjdk.java.net/jdk/jdk/file/61ee15b9a1ac/src/hotspot/share/opto/gcm.cpp#l1352
26-02-2020
The assert is triggered because late scheduling failed but VerifyGraphEdges didn't catch an invalid graph. Assuming the real bug is that scheduling fails although the graph is valid: ILW = Late scheduling fails on valid graph (compilation bailout), triggered by several tests, no workaround = MMH = P3
25-02-2020