United StatesChange Country, Oracle Worldwide Web Sites Communities I am a... I want to...
Bug ID: JDK-6539438 raise_LCA_above_marks stops too early
JDK-6539438 : raise_LCA_above_marks stops too early

Details
Type:
Bug
Submit Date:
2007-03-27
Status:
Resolved
Updated Date:
2010-04-02
Project Name:
JDK
Resolved Date:
2007-04-24
Component:
hotspot
OS:
solaris_9
Sub-Component:
compiler
CPU:
sparc
Priority:
P3
Resolution:
Fixed
Affected Versions:
7
Fixed Versions:
hs10 (b12)

Related Reports
Backport:
Backport:
Relates:

Sub Tasks

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
EVALUATION

The iteration must start from the preds of the current LCA.
                                     
2007-03-27
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
                                     
2007-04-10



Hardware and Software, Engineered to Work Together