I agree with Andrew that the Unsafe API matters, and there are many implementations of it (even multiple within openjdk itself!).
I still know of no reason why my proposed spec is wrong. If C11 support was good and ubiquitous, I would recommend using atomic_compare_exchange_strong or C++ equivalent in the hotspot implementation instead of fences as is done now. If you think you can write a better spec, please share! --- It occurs to me that the Memory Consistency Properties section of the j.u.c. package specs only talk about happens-before, but that should be strengthened to "Synchronization actions" which have a total order. http://docs.oracle.com/javase/specs/jls/se7/html/jls-17.html#jls-17.4.4 On Tue, Mar 10, 2015 at 12:31 AM, Andrew Haley <a...@redhat.com> wrote: > 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.hol...@oracle.com > >> <mailto:david.hol...@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. >
