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

[Martin Buchholz]

On Mon, Mar 9, 2015 at 4:13 AM, David Holmes <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!


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