[jmm-dev] jdk9 APIs [Fences specifically]

[Doug Lea]

On 08/14/2015 02:36 PM, Hans Boehm wrote:

> The more I think about it, the less confident I am that the use
> of "dmb ishst" is actually correct as a constructor barrier to
> start with.

Or, in other words, is dmb ishst guaranteed to implement
any reasonable definition of a storeStoreFence. (Which is
a separate issue than whether storeStoreFences are hard to
use.) I had not considered this possibility, but we do need
to be sure that it applies as expected in cases like:

>
> Thread 1:
> t1.f = 1;   // Final field write in constructor
>         // Implicit constructor StoreStore fence ("dmb ishst") here.
> a = t1; // Correctly publish outside constructor
>
> Thread 2:
> t2.f2 = a;  // Final field write in constructor
>         // Implicit constructor StoreStore fence
> b = t2; // Correctly publish outside constructor
>
> Thread 3:
> if (b != null && b.f2 != null) {
>      t2 = b.f2.f;  // Guaranteed to see 1?
> }
>

The ARM specs are not completely clear about this, so we've asked
them (Stephan Diestelhorst et al) to clarify. If it is the case
that the ARM spec is not intended to require it but all current
processors have the desired effect, the (disappointing) best course
of action seems to be to leave it as non-public within-JDK intrinsic
but not to expose as a Fence.

-Doug