Replace MemBarRelease for final field write with MemBarStoreStore

[Andrew Haley]

On 09/04/2015 04:21 AM, Vitaly Davidovich wrote:

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

I suspect it's 40% better if all you do is create small objects with
final fields and never use those objects.  I suspect this is not the
most common case.  But of course it is significant, and I'd love to
change it.

There's a missed optimization in HotSpot whereby if a object creation
is deleted by escape analysis the barrier is left in place even though
the object is never created.  It would be great if this could be
fixed.  I think the problem is that there is no way to tell if the
barrier at the end of a method is there because of a final field or
it's explicitly inserted by e.g. Unsafe.storeFence().

> 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).

Point taken, but I believe that we'd be better fixing the missed
optimization.

Andrew.