RFR: JDK-8074578 Document memory visibility effects of some Unsafe methods

[Andrew Haley]

On 10/03/15 01:30, David Holmes wrote:
> On 10/03/2015 2:21 AM, Martin Buchholz wrote:
>> On Mon, Mar 9, 2015 at 4:13 AM, David Holmes <david.holmes at oracle.com
>> <mailto:david.holmes at oracle.com>> wrote:
>>
>>     On 9/03/2015 7:27 PM, Andrew Haley wrote:
>>
>>
>>     But who is to say that is the specification for the Unsafe API?
>>
>>
>> It's for us to say!
> 
> I meant specifically the choice of the specification, not the right to 
> suggest one.
> 
>>     The public API's have a specification for what they provide to the
>>     programmer. On what basis are we assigning that same specification
>>     to Unsafe API? The Unsafe API has to meet the requirements of the
>>     public APIs that use it, but that doesn't  mean it necessarily
>>     should have the same specification as those APIs.
>>
>>
>> We already have lots of code that implicitly depends on volatile
>> read/write visibility, especially in j.u.c.
>> Most obviously, how do you implement compareAndSet methods without the
>> same visibility guarantees on the Unsafe equivalents?
> 
> Obviously Unsafe has to be implemented in a way that satisfies the j.u.c 
> routines that use it.
>
>> My spec change only documents what "everyone already knows to be true".
>> Another way of looking at it is that the Unsafe methods are a low-level
>> optimization of the equivalent j.u.c.a. objects without requiring memory
>> allocation.
> 
> The public API methods specify memory ordering semantics so that the
> end programmer can use those to reason about their use of j.u.c
> components.
> 
> The implementation of j.u.c has to satisfy its specified semantics.
> 
> The current implementation of j.u.c uses Unsafe operations that in
> turn utilize JVM operations. The JVM operations have memory
> synchronization affects that are stronger than required by j.u.c,
> and so satisfy them.
> 
> So the question is: should Unsafe specify the expectations of its
> j.u.c client (what you propose); or should it specify what the JVM
> implementations provide; or should it not actually specify anything
> in this regard knowing that the implementation is required to
> correctly implement the public APIs?

Unsafe is an API, so should be specified.  (Whether it's really a
public API has been a matter of some controversy, and people certainly
have treated it as though it were one!)  There is more than one
implementation of some of these methods, and some architectures
(AArch64 is the one I care about the most) have instructions which
implement the JMM requirements perfectly but not anything stronger.
If we were to adopt a stronger API for Unsafe that would slow down
such platforms.

> I don't see much point in pushing down the spec from the public APIs
> to the Unsafe API. To me it suffices to say that the Unsafe methods
> must correctly implement the requirements of the public API without
> specifying that in specific terms of volatile read/writes (which it
> doesn't actually use) or full bi-directional fences (which it does
> use).

It certainly can use volatile read/writes and I would very much like
that to happen (at least on AArch64) before JDK9 is released.

> It's not as if Unsafe were a public API for which we might switch in
> implementations from different providers and hence we need a clear
> specification for those implementors to follow.

Yes it is!  There are other Java VMs which use the OpenJDK class
library, and they will probably have their own Unsafe builtins.

Andrew.