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
|
Java