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

[John Rose]

On Mar 23, 2015, at 1:24 PM, Martin Buchholz <martinrb at google.com> wrote:
> 
> On Wed, Mar 11, 2015 at 2:12 AM, Paul Sandoz <paul.sandoz at oracle.com> wrote:
> 
>> 
>> I am all for clearing up the language here, but think it prudent to hold
>> off doing much until the language for JMM revisions and VarHandle is
>> produced, then we can revisit.
>> 
> 
> I'm disappointed we can't add such a small and safe doc fix now.
> 
> I agree the public docs for replacements for Unsafe methods will be much
> harder (and more important) to get right.  Especially if they include
> wording and API that help those familiar with C/C++11 atomics, as I would
> like.

I have read this thread with interest.

If I understand it correctly, Martin is proposing that we document a semantics for Unsafe CAS that is weak enough to make it convenient to implement on many platforms, but is just strong enough to implement the (known) uses.

David is objecting that since Unsafe is just some native entry points to HotSpot internals (Atomic::cmpxchg), it should promise nothing other than the current behavior (operational semantics).  This behavior might sometimes be overly strong for known use cases, but it is what it is.

So there are standard APIs on the top and the JVM atomics at the bottom, and Unsafe in the middle, being pulled both ways.

Here's my view:  Unsafe exists to provide a reasonably understandable and platform-independent API that JDK libraries can code to.  It is not a "fully public" API in the sense of a JDK specification because although it is portable it cannot be be used securely by untrusted parties.  Of course, it is "public" in the sense of being well-known and widely-used, if not always wisely-used.

Meanwhile, Paul Sandoz is working to refactor these aspects, creating a large chunk of API that will be public, portable, and secure.  You've got to sympathize with him for not wanting to run through all the inevitable arguments about concurrency primitives once for Unsafe and once again later for VarHandles.

My position is this:  Since Unsafe is intended to be portable (though …unsafe) Martin's proposal makes sense.  It is good to firm up the semantics of Unsafe to some portable standard, as long as it doesn't box us into a corner.  Eventually, we may wish (for performance reasons) to weaken some of its guarantees by adjusting its coupling to Atomic::* in HotSpot.

I support the cross-references to C11 semantics, as long as they are descriptive of conditions which are natural to the JMM.  If they are not, we need additional conversations about whether the JMM needs tweaking.  It is of course natural for Unsafe to make references to volatile variable semantics, since they are central to the JMM as it stands today.  And there may be some "wiggle room" matching volatiles to C11, if the fine print of the JMM allows volatiles to be implemented inconsistently from C11 memory_order_seq_cst.  In the end, if we refactor the way we do volatiles, I would expect juc.Atomic* and Unsafe to change at the same time, and it would not be harmful for Martin's javadoc to be in the mix, since we could make new Unsafe API points to reflect an enhanced understanding of what the JVM should do.

So, I think the present proposal makes sense, unless someone can point out some reason what we do (now or in the near future) is inconsistent with C11 atomic_compare_exchange_strong.

And, I applaud Martin's long-running work to firm up the semantics of the mid-layer that Unsafe occupies.

Thanks!
— John