atomicity for value types

Remi Forax forax at
Wed Jan 15 00:52:35 UTC 2020

In the context of Java, we are already using the term 'atomic', in AtomicInteger, AtomicLong, etc, 
and in that case the semantics is volatile + atomic operations (at least CAS), so i think using atomic or any keyword derived from it will not help to our users to understand the semantics for an inline class. 

As Doug said, for a VarHandle, the semantics we want is called opaque, so "opaque" is ok for me. 

Otherwise, the idea is that you can not cut the loads/stores, so "indivisible" is also ok. 


> De: "John Rose" <john.r.rose at>
> À: "valhalla-spec-experts" <valhalla-spec-experts at>
> Envoyé: Mercredi 15 Janvier 2020 01:40:34
> Objet: Re: atomicity for value types

> On Dec 18, 2019, at 5:46 PM, John Rose < [ mailto:john.r.rose at |
> john.r.rose at ] > wrote:

>> - Define a contextual keyword “alwaysatomic" (working title “__AlwaysAtomic”).

> I just referred more carefully to the draft JEP on keyword
> management [ |
> ] and
> realize that it guides us toward a so-called “hyphenated
> contextual keyword” in preference to a “unitary contextual
> keyword”. That is, “always-atomic” is more in keeping with
> that document than “alwaysatomic”.

> I do think this looks more jarring than the unitary keyword:

> always-atomic inline class Cursor { … }

> But, that’s only because it’s an early hyphenated keyword,
> which nobody is eye-trained on yet. If we believe that
> hyphenated keywords are the wave of the future, as I do,
> then we should embrace it, rather than the old-school
> unitary token “alwaysatomic”.

> In the prototype I’m using a temporary (unitary contextual) keyword-ato
> __AlwaysAtomic, plus a temporary annotation @__alwaysatomic__.

> In the JVMs the draft of the corresponding modifier bit looks like this:

> ACC_ALWAYSATOMIC 0x0040 Instances of this inline type are never torn.

More information about the valhalla-spec-observers mailing list