JDK-6791572 : "duplicating node that's already been matched"
  • Type: Bug
  • Component: hotspot
  • Sub-Component: compiler
  • Affected Version: hs14
  • Priority: P3
  • Status: Resolved
  • Resolution: Fixed
  • OS: solaris
  • CPU: x86
  • Submitted: 2009-01-08
  • Updated: 2010-04-04
  • Resolved: 2009-03-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.
JDK 6 JDK 7 Other
6u18Fixed 7Fixed hs15Fixed
Related Reports
Relates :  
When running the dacapo eclipse benchmark with G1 and on Solaris x64 I get the following failure (every time):

# To suppress the following error report, specify this argument
# after -XX: or in .hotspotrc:  SuppressErrorAt=/matcher.cpp:1454
# A fatal error has been detected by the Java Runtime Environment:
#  Internal Error (/java/east/u2/ap31282/hotspot-gc-g1-opt-new/src/share/vm/opto/matcher.cpp:1454), pid=5086, tid=17
#  Error: assert(C->node_arena()->contains(s->_leaf) || !has_new_node(s->_leaf),"duplicating node that's already been matched")
# JRE version: 6.0_04-b12
# Java VM: OpenJDK 64-Bit Server VM (14.0-b09-internal-fastdebug mixed mode solaris-amd64 )
# An error report file with more information is saved as:
# /java/east/u2/ap31282/gc_test_suite_amd64/dacapo/hs_err_pid5086.log
# If you would like to submit a bug report, please visit:
#   http://java.sun.com/webapps/bugreport/crash.jsp

This does not occur on Solaris sparc, sparcv9, or x86, nor it seems to happen without G1 enabled. Here's a command line that will cause it (you of course have to have the dacapo test suite):

java -XX:+UnlockExperimentalVMOptions -XX:+UseG1GC -d64 -XX:+PrintGCTimeStamps -XX:+PrintGCDetails -jar dacapo-2006-10.jar -s default eclipse

PUBLIC COMMENTS Problem: Inputs for an address expression are not checked for and not marked as shared if a non-address node references them before the address expression is processed. Solution: Don't mark inputs for an address expression as shared (don't forced into registers) if they are used only in address expressions. But they should be always marked as shared if there are other uses besides address expressions.

EVALUATION http://hg.openjdk.java.net/jdk7/hotspot-comp/hotspot/rev/6bea93606c11