for review: 8236522: "always atomic" modifier for inline classes to enforce atomicity

Remi Forax forax at
Sat Mar 7 21:41:55 UTC 2020

[Moving to valhalla-spec-experts]

----- Mail original -----
> De: "John Rose" <john.r.rose at>
> À: "Tobias Hartmann" <tobias.hartmann at>
> Cc: "valhalla-dev" <valhalla-dev at>
> Envoyé: Vendredi 21 Février 2020 11:23:14
> Objet: Re: for review: 8236522: "always atomic" modifier for inline classes to enforce atomicity

> I’ve come back around to this feature, after (SMH) realizing
> it should be a marker interface (java.lang.NonTearable) instead
> of a new modifier and access flag.  Thanks, Brian…

In my opinion, using an annotation here cross the rubicon,
user available annotations are not supposed to change the semantics of a language construct, they are metadata.

Do you really want the memory model to make reference of an annotation ?
Or worst, do you think that you can avoid to change the JMM to describe the effects of always atomic inline classes ?

What is the reason to change/move the line here ?
Are you envisioning other annotations that can change the semantics ?

Why can not be a keyword at source level and an attribute at classfile level ?


> Also, I’ve re-integrated my changes on top of the signature
> changes and field layout changes.
> Please have another look:
> (Old webrev is atomic-8236522.1)
> — John
> P.S. There’s a slightly over-engineered string matcher included.
> I intend to use it for other purposes as well, when there are
> ad hoc class lists to assign special properties to, such as
> “please track locking events” and so on.  The code in
> CompilerOracle was not repurposable, sadly.
>> On Feb 12, 2020, at 7:36 AM, Tobias Hartmann <tobias.hartmann at> wrote:
>> Hi John,
>> I've just sent the RFR for 8238780 which will fix these issues. I found one
>> additional place where a
>> StoreStore barrier was missing.
>> Thanks,
>> Tobias
>> On 22.01.20 21:20, John Rose wrote:
>>> On Jan 20, 2020, at 6:54 AM, Tobias Hartmann <tobias.hartmann at
>>> <mailto:tobias.hartmann at>> wrote:
>>>>> How did it reproduce for you? It would be nice to have a regression test.
>>>> Okay, -XX:+StressLCM did the trick :)
>>> Thanks for taking it out for a spin.
>>> The jtreg test failed reliably (P ~ 50%)
>>> on my MacBook.  Debugging that led me to add that S-S barrier.
> >> — John

More information about the valhalla-spec-observers mailing list