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

[Remi Forax]

[Moving to valhalla-spec-experts]

----- Mail original -----
> De: "John Rose" <john.r.rose at oracle.com>
> À: "Tobias Hartmann" <tobias.hartmann at oracle.com>
> Cc: "valhalla-dev" <valhalla-dev at openjdk.java.net>
> 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 ?

Rémi

> 
> Also, I’ve re-integrated my changes on top of the signature
> changes and field layout changes.
> 
> Please have another look:
> 
> http://cr.openjdk.java.net/~jrose/values/atomic-8236522
> 
> (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 oracle.com> 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 oracle.com
>>> <mailto:tobias.hartmann at oracle.com>> 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 ValueTearing.java failed reliably (P ~ 50%)
>>> on my MacBook.  Debugging that led me to add that S-S barrier.
>>> 
> >> — John