review for 7032963: StoreCM shouldn't participate in store elimination

Tom Rodriguez tom.rodriguez at oracle.com
Tue Apr 5 15:09:39 PDT 2011


On Apr 1, 2011, at 3:13 PM, Y. Srinivas Ramakrishna wrote:

> On 4/1/2011 2:55 PM, Tom Rodriguez wrote:
>> I could push this to hotspot-gc so it gets more CMS testing .
> 
> That would be a very good idea (CMS as well as G1 testing, actually)!
> 
> I can't review your changes, lacking sufficient bkgrd or
> familiarity with the code, but ...

So I was going to push this to hotspot-gc.  Is that ok?  It won't make nightly testing tonight...

tom

> 
>> This actually
>>> eliminates duplicates that were previously missed so the code quality
>>> is slightly better.
> 
> wow! What more could one ask for --you fixed a correctness
> bug _and_ got us a bit more performance. Hmm, by chance does
> the fix also come with a free bottle of beer for all of us? ;-)
> 
> -- ramki
> 
>> 
>> http://cr.openjdk.java.net/~never/7032963
>> 
>> 7032963: StoreCM shouldn't participate in store elimination
>> Reviewed-by:
>> 
>> StoreCM shouldn't participate in redundant store elimination since
>> that could violate the requirement that a StoreCM must be strictly
>> after a field update.  This results in a large number of redundant
>> StoreCMs being emitted for blocks of fields updates, so I added an
>> optimization to fold them up safely.  Previously the extra dependence
>> was converted into a precedence edge just before register allocation
>> but I moved this logic into final_graph_reshape.  I then added logic
>> to search through chains of StoreCMs to eliminate earlier redundant
>> ones and transfer their precedence edges to the one that is kept.
>> This ensures that they are scheduled properly.  This actually
>> eliminates duplicates that were previously missed so the code quality
>> is slightly better.  Tested by inspecting code generation with script
>> to identify duplicates.  Also ran CTW with -XX:+UseCondCardMark and
>> -XX:+UseG1GC.
>> 
> 



More information about the hotspot-compiler-dev mailing list