JDK-6539438 : raise_LCA_above_marks stops too early
  • Type: Bug
  • Component: hotspot
  • Sub-Component: compiler
  • Affected Version: 7
  • Priority: P3
  • Status: Resolved
  • Resolution: Fixed
  • OS: solaris_9
  • CPU: sparc
  • Submitted: 2007-03-27
  • Updated: 2010-04-02
  • Resolved: 2007-04-24
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
6u4Fixed 7Fixed hs10Fixed
Related Reports
Relates :  
JDK-6470497 - early C2 cleanups for Java 7
Description
The fix for 6470497 changed the anti-dependence code which searches for a new LCA for a load based on the blocks containing stores that might be anti-dependent.  The rewrite converted a recursive algorithm to a worklist based one but started the search at an earlier block.  This can cause the search to terminate early results in bad scheduling of loads and stores.
Comments
SUGGESTED FIX Original workspace: smite:/export/ws/6539438 Parent workspace: /net/jano.sfbay/export/disk05/hotspot/ws/main/c2_baseline Submitter: never PRT data: /net/prt-web.sfbay/prt-workspaces/20070410133203.never.6539438 Archived data: /net/prt-archiver.sfbay/data/archived_workspaces/main/c2_baseline/2007/20070410133203.never.6539438/ Webrev: http://prt-web.sfbay.sun.com/net/prt-archiver.sfbay/data/archived_workspaces/main/c2_baseline/2007/20070410133203.never.6539438/workspace/webrevs/webrev-2007.04.10/index.html Fixed 6539438: raise_LCA_above_marks stops too early The fix for 6470497 converted raise_LCA_above_marks from a recursive algorithm to a work list based one but changed it subtly by accident. In the original algorithm the search started from the predecessors of the current LCA but when it was rewritten that was broken which could cause the search to abort prematurely. Even in the case where it didn't raise the LCA properly it was still likely for the code to work correctly, since most of the time this code doesn't need to raise the LCA. I fixed the algorithm and checked how often it returned the wrong answer. About 40 times in specjvm98 it returns the wrong value but in all those cases the code still executes correctly. It also happens about 5 times in jbb2005 without causing a problem. Otherwise it doesn't happen at all in refworkload. So the fix is when looking at the LCA always place it's predecessors on the work list. I added code to allow insert_anti_dependence to verify that the block the load is finally placed in has the proper precedence edges as well, which detects the original bug about 20 times in the a full CTW run. http://javaweb.sfbay/~never/webrev/6539438 Reviewed by: kvn, sgoldman Fix verified (y/n): y failing specjvm98 case CTW without fix but with verification CTW with verification
10-04-2007
EVALUATION The iteration must start from the preds of the current LCA.
27-03-2007