for review: 8236522: "always atomic" modifier for inline classes to enforce atomicity
forax at univ-mlv.fr
Sat Mar 7 21:41:55 UTC 2020
[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 ?
> 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 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.
>> 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
More information about the valhalla-spec-observers