Replace MemBarRelease for final field write with MemBarStoreStore

[Vitaly Davidovich]

I can certainly understand the decision to play conservative here in light
of this being a dark corner.  But on the other hand, one can argue that
being conservative here "encourages" (or at least doesn't slap on the
wrist) people doing this.  On top of that, it seems Hui identified this as
a performance problem on some impl of aarch64 (personally, I don't have a
horse in this race since the archs I use nop the LoadStore|StoreStore
combo); a 40% perf boost is nothing to sneeze at, IMHO.

Having said that, could you please modify the JMM cookbook to stipulate
this for final fields in the meantime?

On Wed, Sep 2, 2015 at 11:21 AM, Doug Lea <dl at cs.oswego.edu> wrote:

> On 09/02/2015 11:08 AM, Vitaly Davidovich wrote:
>
>>
>> I'm not sure "accommodating" capturing racy memory is required
>> here.
>>
>> Hans' actual example isn't applicable to final/stable fields because they
>> cannot
>> be mutated after assignment.  You introduced a racy read in your example,
>> and I
>> don't know if that's valid.
>>
>
> The existing JSR133 JMM specs and final field rules do not provide an
> answer.
> And the JMM will not be updated for jdk9. For VarHandle usages, we
> can specify what happens when you use them (thus resolving the issue
> in those cases). But for other usages, the answer is murky, and
> most people think that reducing surprise is the best decision.
>
> -Doug
>
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.openjdk.java.net/pipermail/hotspot-compiler-dev/attachments/20150902/e1e34933/attachment.html>