Replace MemBarRelease for final field write with MemBarStoreStore

[Vitaly Davidovich]

Sure, we can wait for hardware manufacturers to lower the cost of barriers,
but at the same time, compilers need to generate code that benefits today's
hardware and not some theoretically better future one.  Hui claims 40%
better performance, that's very significant.  Java programmers are
encouraged to use final fields as much as possible, so this leaves
substantial performance on the table for a very common case for a case that
isn't spec'd and flat out asking for trouble to begin with (i.e. Aleksey's
example with racy G).

sent from my phone
On Sep 3, 2015 11:28 AM, "Andrew Haley" <aph at redhat.com> wrote:

> On 09/03/2015 04:21 PM, Hui Shi wrote:
>
> > Breaking dependency between final stores and loads it depends on
> > introduce loadstore barrier. To solve similar corner cases, JIT need
> > ensure no final stores's depended load is reordered with store in
> > JIT optimization. Then JIT can weakening Memory Barrier here. This
> > has some chance to missing optimization for final store, but is
> > worthwhile on RMO platform like aarch64.
>
> Well, maybe, maybe not.  It all depends on how efficient loadstore
> barriers are, and how useful the optimizations in question are.  At
> the present time it makes the most sense for programmers to say what
> we mean and encourage hardware designers to make barriers more
> efficient.  We have already come a long way, and IMO it doesn't make a
> huge amount of sense right now to nit-pick the finer details of memory
> barrier optimizations but to be conservative.
>
> Andrew.
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.openjdk.java.net/pipermail/hotspot-compiler-dev/attachments/20150903/3ee5afed/attachment.html>