[concurrency-interest] RFR: 8065804: JEP 171: Clarifications/corrections for fence intrinsics

[Martin Buchholz]

On Wed, Dec 10, 2014 at 1:02 PM, Andrew Haley <aph at redhat.com> wrote:
> On 12/05/2014 09:49 PM, Martin Buchholz wrote:
>> The actual implementations of storestore (see below) seem to
>> universally give you the stronger ::release barrier, and it seems
>> likely that hotspot engineers are implicitly relying on that, that
>> some uses of ::storestore in the hotspot sources are bugs (should be
>> ::release instead) and that there is very little potential performance
>> benefit from using ::storestore instead of ::release, precisely
>> because the additional loadstore barrier is very close to free on all
>> current hardware.
>
> That's not really true for ARM, where the additional loadstore requires
> a full barrier.  There is a good use for a storestore, which is when
> zeroing a newly-created object.

Andrew and David,

I agree that given ARM's decision to provide the choice of StoreStore
and full fences, hotspot is right to use them in a few carefully
chosen places, like object initializers.

But ARM's decision seems poor to me. No mainstream language (like
C/C++ or Java) is likely to support those in any way accessible to
user programs (not even via Java Unsafe).  Making their StoreStore
barrier also do LoadStore would dramatically increase the
applicability of their instruction with low cost.  Maybe it's not too
late for ARM to do so.