JDK-8162496 : missing precedence edge for anti_dependence
  • Type: Bug
  • Component: hotspot
  • Sub-Component: compiler
  • Affected Version: 8u92,9
  • Priority: P4
  • Status: Resolved
  • Resolution: Fixed
  • OS: generic
  • CPU: generic
  • Submitted: 2016-07-25
  • Updated: 2017-11-29
  • Resolved: 2016-08-18
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.
8u152Fixed 9 b137Fixed
Related Reports
Relates :  
JDK-8157306 original changes added assert for anti_dependence edges after GCM:

Unfortunately it triggered more failures than fixed by JDK-8157306 changes.
Since that fix was critical for AARCH 64 project we decided to push it without assert and file this bug which will fix the rest of failures.

We may need to backport this and 8157306 fixes.

#  Internal Error (hotspot/src/share/vm/opto/gcm.cpp:788), pid=14456, tid=28
#  assert(store->find_edge(load) != -1) failed: missing precedence edge

jtreg should be run with -vmoptions:'-Xcomp' to reproduce failures.

No new tests were added since the problem showed with existing Hotspot jtreg tests

Fix in addition to assert: src/share/vm/opto/lcm.cpp @@ -437,6 +437,18 @@ latency_from_uses(nul_chk); latency_from_uses(best); + + // insert anti-dependences to defs in this block + if (! best->needs_anti_dependence_check()) { + for (uint k = 1; k < block->number_of_nodes(); k++) { + Node *n = block->get_node(k); + if (n->needs_anti_dependence_check() && + n->in(LoadNode::Memory) == best->in(StoreNode::Memory)) { + // Found anti-dependent load + insert_anti_dependences(block, n); + } + } + } }

9-defer-SQE-ok: agreed on deferral reason

9-defer-request: This failure only shows up with verification code that is currently not enabled. It's not clear if the failures are even "real" problems or if the verification code needs to be fixed because it's too strong. There are no known related problems.

ILW = Potential problem, only shows up with currently not enabled verification code, no workaround = MLH = P4