RFC (S) JDK-8050149: Experimental option to select the instruction sequence for x86 StoreLoad barrier

[Vitaly Davidovich]

Shouldn't store forwarding resolve (in the cases where it's allowed) the
RAW hazards?

Sure, I think it's good to test this stuff out.  I'm just "thinking out
loud" here as it seems that optimizing data dependency chain around an
expensive instruction wouldn't yield any significant gains in real code
(i.e. I'm sure some microbenchmark can be constructed to show otherwise),
but I'd be very interested if someone can explain it (even if you find some
combination of StoreLoad that works best empirically, it'd be good to
actually have some sort of explanation as to why).




On Mon, Jul 14, 2014 at 6:39 PM, Aleksey Shipilev <
aleksey.shipilev at oracle.com> wrote:

> On 07/15/2014 02:30 AM, Vitaly Davidovich wrote:
> > Wouldn't the cost be dominated by the hardware fence though? Even if you
> > carry a data dependency here, it seems like real-life performance would
> > degrade due to store buffer drain stall, no? This seems like trying to
> > shed a few pounds off an elephant.
>
> <...>
>
> > Also, presumably with out of order execution the register renamer should
> > allow for speculation to proceed assuming rsp is resolved in time, which
> > it should given that memory is in cache.
>
> Renaming resolves WAW and WAR hazards. RAW hazards are not resolved by
> renaming. See https://bugs.openjdk.java.net/browse/JDK-8050147, and/or
> http://cr.openjdk.java.net/~shade/8050147/orig.perfasm for the example
> of RAW hazard. There are real life cases we are following up, but
> whether it is "real" enough depends on further wide-scale testing. I
> would prefer to gather all the crazy ideas and run them once at this point.
>
> -Aleksey.
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.openjdk.java.net/pipermail/hotspot-compiler-dev/attachments/20140714/55d34777/attachment.html>