Replace MemBarRelease for final field write with MemBarStoreStore
aph at redhat.com
Fri Sep 4 08:28:15 UTC 2015
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
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
More information about the hotspot-compiler-dev