[Moving to valhalla-spec-experts] ----- Mail original ----- > De: "John Rose" <john.r.r...@oracle.com> > À: "Tobias Hartmann" <tobias.hartm...@oracle.com> > Cc: "valhalla-dev" <valhalla-...@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.hartm...@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.hartm...@oracle.com >>> <mailto:tobias.hartm...@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
