JDK-6732698 : crash with dead code from compressed oops in gcm
  • Type: Bug
  • Component: hotspot
  • Sub-Component: compiler
  • Affected Version: hs14
  • Priority: P1
  • Status: Resolved
  • Resolution: Fixed
  • OS: solaris_9
  • CPU: sparc
  • Submitted: 2008-08-01
  • Updated: 2010-04-02
  • Resolved: 2008-09-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 6 JDK 7 Other
6u14Fixed 7Fixed hs14Fixed
Related Reports
Relates :  
During promotion for b32 crashes on linux-amd64 and windows-amd64 occurred during the build when executing pack.  There seems to be some cloning of loadN nodes going on during matching that should be and this result in some dead loadN nodes still connected to the graph.  gcm dies in this code:

      uint use_rpo = _bbs[use->_idx]->_rpo;

because they haven't been scheduled yet so _bbs returns NULL.  The use is a dead loadN.

 1123   loadN   === _ o711  893  [[ 1121 ]] narrowoop: java/util/HashMap:NotNull:exact *
 1122   loadN   === _ o711  893  [[ 1121 ]] narrowoop: java/util/HashMap:NotNull:exact *
o711    Proj    === o709  [[o881 o720 o4488 o788 o733 o785 o783 o965 o772 o878 o756 o838 o848 o823 o980 o950 o908 o912 o4467 o4473 o4519 o4565 o4631 o4784 o4791  892  1122  1123  1121 ]] #2  Memory: @BotPTR *+bot, idx=Bot;
o4241   IfFalse === o4240  [[o4480 o4473  1121 ]] #0
 1121   incI_mem        === o4241 o711  1122  1123  [[]] memory  Memory: @java/util/HashMap:NotNull:exact+32 *, name=modCount, idx=24;

The incI_mem somehow wasn't matched correctly since it ended up with two different copies of the loadN instead of two references to the same node.  The del_req call in incI_memNode::Expand removes one reference which causes it to go dead.  So the problem seem to be that matching gives us two copies instead of one.

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