From forax at univ-mlv.fr Sat Mar 7 21:41:55 2020 From: forax at univ-mlv.fr (Remi Forax) Date: Sat, 7 Mar 2020 22:41:55 +0100 (CET) Subject: for review: 8236522: "always atomic" modifier for inline classes to enforce atomicity In-Reply-To: <02631A77-BA89-41DF-A705-225F4D9AF843@oracle.com> References: <212B1143-F1F9-45AF-8ADD-E44513BA7050@oracle.com>

<6f201ace-f9e6-1ed9-6187-1e881c146d56@oracle.com> <83A8E7C7-C2CB-4F3C-A840-F6169C9E6246@oracle.com> <1113acf6-9c46-5e07-ed07-679bca4e3a94@oracle.com> <02631A77-BA89-41DF-A705-225F4D9AF843@oracle.com> Message-ID: <508511245.1216273.1583617315082.JavaMail.zimbra@u-pem.fr> [Moving to valhalla-spec-experts] ----- Mail original ----- > De: "John Rose" > ?: "Tobias Hartmann" > Cc: "valhalla-dev" > 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 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 >> > 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 From john.r.rose at oracle.com Sat Mar 7 21:52:12 2020 From: john.r.rose at oracle.com (John Rose) Date: Sat, 7 Mar 2020 13:52:12 -0800 Subject: for review: 8236522: "always atomic" modifier for inline classes to enforce atomicity In-Reply-To: <508511245.1216273.1583617315082.JavaMail.zimbra@u-pem.fr> References: <212B1143-F1F9-45AF-8ADD-E44513BA7050@oracle.com>

<6f201ace-f9e6-1ed9-6187-1e881c146d56@oracle.com> <83A8E7C7-C2CB-4F3C-A840-F6169C9E6246@oracle.com> <1113acf6-9c46-5e07-ed07-679bca4e3a94@oracle.com> <02631A77-BA89-41DF-A705-225F4D9AF843@oracle.com> <508511245.1216273.1583617315082.JavaMail.zimbra@u-pem.fr> Message-ID: On Mar 7, 2020, at 1:41 PM, Remi Forax wrote: > > [Moving to valhalla-spec-experts] > > ----- Mail original ----- >> De: "John Rose" >> ?: "Tobias Hartmann" >> Cc: "valhalla-dev" >> 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. I agree. > Do you really want the memory model to make reference of an annotation ? No. > Or worst, do you think that you can avoid to change the JMM to describe the effects of always atomic inline classes ? The JMM has to change, but it doesn?t have to mention any Java syntax. I?m anticipating that we adjust the existing language about tearing of longs and doubles to cover values also. > 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 ? So, that?s a different question. It shouldn?t be that either, IMO, because that is also disruptive to the specifications. Keywords and attributes cost a lot to specify and implement, right? I prototyped a keyword, and backed away to a marker interface, which I think is the right answer. So: not an annotation, not a keyword, but a marker interface. It is certainly the path of least resistance for a prototype, so we?re doing that right now. It might even be the right answer in the long run. Here?s the current draft java doc for java.lang.NonTearable: > An inline class implements the {@code NonTearable} interface to > request that the JVM take extra care to avoid structure tearing > when loading or storing any value of the class to a field or array > element. Normally, only fields declared {@code volatile} are > protected against structure tearing, but a class that implements > this marker interface will never have its values torn, even when > they are stored in array elements or in non-{@code volatile} > fields, and even when multiple threads perform racing writes. > >

An inline instance of multiple components is said to be "torn" > when two racing threads compete to write those components, and one > thread writes some components while another thread writes other > components, so a subsequent observer will read a hybrid composed, > as if "out of thin air", of field values from both racing writes. > Tearing can also occur when the effects of two non-racing writes > are observed by a racing read. In general, structure tearing > requires a read and two writes (initialization counting as a write) > of a multi-component value, with a race between any two of the > accesses. The effect can also be described as if the Java memory > model break up inline instance reads and writes into reads and > writes of their various fields, as it does with longs and doubles > (JLS 17.7). > >

In extreme cases, the hybrid observed after structure tearing > might be a value which is impossible to construct by normal means. > If data integrity or security depends on proper construction, > the class should be declared as implementing {@code NonTearable}. Also, we could add a paragraph giving full disclosure about the meaninglessness of having non-inlines implement NonTearable, or maybe in the end we can position NonTearable in a place where non-inlines cannot implement it. I?m inclined to leave it out for now, at least until we figure out the shape of the type hierarchy immediately under Object. Comments? ? John From forax at univ-mlv.fr Sat Mar 7 22:22:05 2020 From: forax at univ-mlv.fr (forax at univ-mlv.fr) Date: Sat, 7 Mar 2020 23:22:05 +0100 (CET) Subject: for review: 8236522: "always atomic" modifier for inline classes to enforce atomicity In-Reply-To: References: <212B1143-F1F9-45AF-8ADD-E44513BA7050@oracle.com> <6f201ace-f9e6-1ed9-6187-1e881c146d56@oracle.com> <83A8E7C7-C2CB-4F3C-A840-F6169C9E6246@oracle.com> <1113acf6-9c46-5e07-ed07-679bca4e3a94@oracle.com> <02631A77-BA89-41DF-A705-225F4D9AF843@oracle.com> <508511245.1216273.1583617315082.JavaMail.zimbra@u-pem.fr> Message-ID: <563300793.1220176.1583619725495.JavaMail.zimbra@u-pem.fr> ----- Mail original ----- > De: "John Rose" > ?: "Remi Forax" > Cc: "valhalla-spec-experts" > Envoy?: Samedi 7 Mars 2020 22:52:12 > Objet: Re: for review: 8236522: "always atomic" modifier for inline classes to enforce atomicity > On Mar 7, 2020, at 1:41 PM, Remi Forax wrote: >> >> [Moving to valhalla-spec-experts] >> >> ----- Mail original ----- >>> De: "John Rose" >>> ?: "Tobias Hartmann" >>> Cc: "valhalla-dev" >>> 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. > > I agree. > >> Do you really want the memory model to make reference of an annotation ? > > No. > >> Or worst, do you think that you can avoid to change the JMM to describe the >> effects of always atomic inline classes ? > > The JMM has to change, but it doesn?t have to mention any Java syntax. > I?m anticipating that we adjust the existing language about tearing of > longs and doubles to cover values also. > >> 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 ? > > > So, that?s a different question. It shouldn?t be that either, IMO, because > that is also disruptive to the specifications. Keywords and attributes > cost a lot to specify and implement, right? yes, but cutting corners inflates the bill of later releases. A cost that you know may be better than a cost that is hard to evaluate. > I prototyped a keyword, and backed away to a marker interface, which I think is the right answer. Marker interface are usually problematic because: - they can inherited, for inline classes, you can put them on our new kind of abstract class, which will make things just harder to diagnose. - they can be uses as a type, like Serializable is used where it should not. By example, what an array of java.lang.NonTearable means exactly. There is a potential for a lot of confusion. and in the specific case of NonTerable, a non inline class can implement it, again creating confusion. > > So: not an annotation, not a keyword, but a marker interface. > It is certainly the path of least resistance for a prototype, so we?re > doing that right now. It might even be the right answer in the long > run. Here?s the current draft java doc for java.lang.NonTearable: If it's for a prototype, i see no problem apart the name, the name should start with underscores to make it clears that this is a temporary construct. > >> An inline class implements the {@code NonTearable} interface to >> request that the JVM take extra care to avoid structure tearing >> when loading or storing any value of the class to a field or array >> element. Normally, only fields declared {@code volatile} are >> protected against structure tearing, but a class that implements >> this marker interface will never have its values torn, even when >> they are stored in array elements or in non-{@code volatile} >> fields, and even when multiple threads perform racing writes. >> >>

An inline instance of multiple components is said to be "torn" >> when two racing threads compete to write those components, and one >> thread writes some components while another thread writes other >> components, so a subsequent observer will read a hybrid composed, >> as if "out of thin air", of field values from both racing writes. >> Tearing can also occur when the effects of two non-racing writes >> are observed by a racing read. In general, structure tearing >> requires a read and two writes (initialization counting as a write) >> of a multi-component value, with a race between any two of the >> accesses. The effect can also be described as if the Java memory >> model break up inline instance reads and writes into reads and >> writes of their various fields, as it does with longs and doubles >> (JLS 17.7). >> >>

In extreme cases, the hybrid observed after structure tearing >> might be a value which is impossible to construct by normal means. >> If data integrity or security depends on proper construction, >> the class should be declared as implementing {@code NonTearable}. > > Also, we could add a paragraph giving full disclosure about the > meaninglessness of having non-inlines implement NonTearable, > or maybe in the end we can position NonTearable in a > place where non-inlines cannot implement it. I?m inclined to > leave it out for now, at least until we figure out the shape of the > type hierarchy immediately under Object. that the problem of choosing a mecanism, an interface, that can be inherited. > > Comments? > > ? John R?mi From john.r.rose at oracle.com Sat Mar 7 23:18:30 2020 From: john.r.rose at oracle.com (John Rose) Date: Sat, 7 Mar 2020 15:18:30 -0800 Subject: for review: 8236522: "always atomic" modifier for inline classes to enforce atomicity In-Reply-To: <563300793.1220176.1583619725495.JavaMail.zimbra@u-pem.fr> References: <212B1143-F1F9-45AF-8ADD-E44513BA7050@oracle.com> <6f201ace-f9e6-1ed9-6187-1e881c146d56@oracle.com> <83A8E7C7-C2CB-4F3C-A840-F6169C9E6246@oracle.com> <1113acf6-9c46-5e07-ed07-679bca4e3a94@oracle.com> <02631A77-BA89-41DF-A705-225F4D9AF843@oracle.com> <508511245.1216273.1583617315082.JavaMail.zimbra@u-pem.fr> <563300793.1220176.1583619725495.JavaMail.zimbra@u-pem.fr> Message-ID: <1C98F7F9-DEF1-4D9B-802F-BBFDEE3C7729@oracle.com> On Mar 7, 2020, at 2:22 PM, forax at univ-mlv.fr wrote: > > Marker interface are usually problematic because: > - they can inherited, for inline classes, you can put them on our new kind of abstract class, which will make things just harder to diagnose. As always the flexibility of inheritance cuts both ways. Suppose I define AbstractSlice with subtypes MemorySlice, ArraySlice, etc. and I intend it for secure applications. I then mark AbstractSlice as NonTearable, and all its subs are therefore also NonTearable. You cannot do that with an ad hoc keyword, even if you want to. You have to make sure that every concrete subtype mentions the keyword. It?s a trade-off, of course, but for me the cost of a new keyword pushes me towards using types making the property inherited. It?s a decision which falls squarely in the center of the language. > - they can be uses as a type, like Serializable is used where it should not. > By example, what an array of java.lang.NonTearable means exactly. There is a potential for a lot of confusion. Again, if I have an algorithm that works for a range of value types (via an interface or abstract super), I can express the requirement that the inputs to the algorithm be non-tearable, using subtypes. For example, the bound (Record & NonTearable) expresses and enforces the intention that the algorithm will operate on non-tearable record values. > and in the specific case of NonTerable, a non inline class can implement it, again creating confusion. The confusion comes from the incomplete story here. I?d like to suggest that IdentityObject implements NonTearable, so that bounds like Record & NonTearable allow identity and inline objects. ? John From brian.goetz at oracle.com Mon Mar 9 15:13:21 2020 From: brian.goetz at oracle.com (Brian Goetz) Date: Mon, 9 Mar 2020 11:13:21 -0400 Subject: for review: 8236522: "always atomic" modifier for inline classes to enforce atomicity In-Reply-To: <1C98F7F9-DEF1-4D9B-802F-BBFDEE3C7729@oracle.com> References: <212B1143-F1F9-45AF-8ADD-E44513BA7050@oracle.com> <6f201ace-f9e6-1ed9-6187-1e881c146d56@oracle.com> <83A8E7C7-C2CB-4F3C-A840-F6169C9E6246@oracle.com> <1113acf6-9c46-5e07-ed07-679bca4e3a94@oracle.com> <02631A77-BA89-41DF-A705-225F4D9AF843@oracle.com> <508511245.1216273.1583617315082.JavaMail.zimbra@u-pem.fr> <563300793.1220176.1583619725495.JavaMail.zimbra@u-pem.fr> <1C98F7F9-DEF1-4D9B-802F-BBFDEE3C7729@oracle.com> Message-ID: <7822fff4-83eb-6002-964f-52ea8b3e796b@oracle.com> While this makes sense (references to identity objects are non-tearable), I'm not sure that is what the users will actually take away from what you propose.? If a user sees the equivalent of: ``` class Point implements NonTearable { ??? int x; ??? int y; } ``` this is pretty easy to misinterpret.? And, unlike IdentityObject, I don't really see the static type ever being used as a type (e.g., ``.) Non-tearability is a low-level thing; attaching it to identity classes makes that harder to see. On 3/7/2020 6:18 PM, John Rose wrote: > I?d like to > suggest that IdentityObject implements NonTearable, so that > bounds like Record & NonTearable allow identity and inline > objects. From peter.levart at gmail.com Sat Mar 14 11:01:38 2020 From: peter.levart at gmail.com (Peter Levart) Date: Sat, 14 Mar 2020 12:01:38 +0100 Subject: for review: 8236522: "always atomic" modifier for inline classes to enforce atomicity In-Reply-To: References: <212B1143-F1F9-45AF-8ADD-E44513BA7050@oracle.com> <6f201ace-f9e6-1ed9-6187-1e881c146d56@oracle.com> <83A8E7C7-C2CB-4F3C-A840-F6169C9E6246@oracle.com> <1113acf6-9c46-5e07-ed07-679bca4e3a94@oracle.com> <02631A77-BA89-41DF-A705-225F4D9AF843@oracle.com> <508511245.1216273.1583617315082.JavaMail.zimbra@u-pem.fr> Message-ID: <72a0caf1-22b9-05fb-c429-a15be60fc461@gmail.com> Hi, Comments inline... On 3/7/20 10:52 PM, John Rose wrote: > Here?s the current draft java doc for java.lang.NonTearable: > >> An inline class implements the {@code NonTearable} interface to >> request that the JVM take extra care to avoid structure tearing >> when loading or storing any value of the class to a field or array >> element. Normally, only fields declared {@code volatile} are >> protected against structure tearing, but a class that implements >> this marker interface will never have its values torn, even when >> they are stored in array elements or in non-{@code volatile} >> fields, and even when multiple threads perform racing writes. What about final fields? In current JMM they imply there is a happens before between end of constructor (where they are written to) and any read of them even after racy publication of an instance. So in effect final fields (in non-inline classes) behave as though they are written to only once (there's no pre-initialization write that would be visible). So I would expect no tearing to be visible too. Am I right to assume that an inline type whose value is assigned to a final field of non-inline type need not be declared NonTearable ? If I'm right, then final modifier on a field could be used to declare inline classes that don't allow tearing. All fields of inline classes are implicitly final. But does that implicitness extends to non-tearability too? For example: inline class Tearable { ??? long x, y; } inline class TearableOrNot { ??? Tearable t; } The 't' field is implicitly final. So does TearableOrNot allow tearing the t.x and t.y apart or not? If it doesn't then perhaps this could be a way to express non-tearability of inline types. Another option would be that fields of inline types are implicitly final but that only means they can't be assigned to twice in constructor or even once outside of constructor - it doesn't extend to non-tearability. For non-tearability they would have to be explicitly declared as final. But that would be confusing I think. It is already a little confusing, because in non-inline classes, declaring all fields final means that no tearing is possible. Not so in inline class where all fields are implicitly final already. But that distinction on the 1st level could be learned to live with. Regards, Peter >> >>

An inline instance of multiple components is said to be "torn" >>> when two racing threads compete to write those components, and one >>> thread writes some components while another thread writes other >>> components, so a subsequent observer will read a hybrid composed, >>> as if "out of thin air", of field values from both racing writes. >>> Tearing can also occur when the effects of two non-racing writes >>> are observed by a racing read. In general, structure tearing >>> requires a read and two writes (initialization counting as a write) >>> of a multi-component value, with a race between any two of the >>> accesses. The effect can also be described as if the Java memory >>> model break up inline instance reads and writes into reads and >>> writes of their various fields, as it does with longs and doubles >>> (JLS 17.7). >>> >>>

In extreme cases, the hybrid observed after structure tearing >>> might be a value which is impossible to construct by normal means. >>> If data integrity or security depends on proper construction, >>> the class should be declared as implementing {@code NonTearable}. >> Also, we could add a paragraph giving full disclosure about the >> meaninglessness of having non-inlines implement NonTearable, >> or maybe in the end we can position NonTearable in a >> place where non-inlines cannot implement it. I?m inclined to >> leave it out for now, at least until we figure out the shape of the >> type hierarchy immediately under Object. >> >> Comments? > From forax at univ-mlv.fr Wed Mar 25 17:37:58 2020 From: forax at univ-mlv.fr (Remi Forax) Date: Wed, 25 Mar 2020 18:37:58 +0100 (CET) Subject: java.lang.Record vs InlineObject/IdentityObject Message-ID: <1972459922.2078642.1585157878030.JavaMail.zimbra@u-pem.fr> Hi, currently a record can only be an IdentityObject but at some point, we want to introduce an inline record ? Now the question: What the subtyping relation between java.lang.Record and InlineObject/IdentityObject ? An identity record (resp. an inline record) should be a subtype of both java.lang.Record and IdentityObject (resp InlineObject). Given that java.lang.Record has to be an abstract class because you can not re-abstract an interface method. So both IdentityObject and InlineObject are interface and java.lang.Record inherits from Object. Am i right ? Or do we really care about re-abstracting the methods of j.l.Record ? regards, R?mi From brian.goetz at oracle.com Wed Mar 25 19:16:24 2020 From: brian.goetz at oracle.com (Brian Goetz) Date: Wed, 25 Mar 2020 15:16:24 -0400 Subject: java.lang.Record vs InlineObject/IdentityObject In-Reply-To: <1972459922.2078642.1585157878030.JavaMail.zimbra@u-pem.fr> References: <1972459922.2078642.1585157878030.JavaMail.zimbra@u-pem.fr> Message-ID: <9fe1bbae-4181-ef0b-1b78-bb5475ac006f@oracle.com> > currently a record can only be an IdentityObject but at some point, we want to introduce an inline record ? Indeed so. > Now the question: What the subtyping relation between java.lang.Record and InlineObject/IdentityObject ? > > An identity record (resp. an inline record) should be a subtype of both java.lang.Record and IdentityObject (resp InlineObject). > Given that java.lang.Record has to be an abstract class because you can not re-abstract an interface method. > So both IdentityObject and InlineObject are interface and java.lang.Record inherits from Object. > > Am i right ? > Or do we really care about re-abstracting the methods of j.l.Record ? > This is right.? j.l.Record will be one of those "inline-friendly abstract classes", which can be a superclass for either identity or inline records.? (Enum will not be, as it has fields.) From brian.goetz at oracle.com Fri Mar 27 19:59:38 2020 From: brian.goetz at oracle.com (Brian Goetz) Date: Fri, 27 Mar 2020 15:59:38 -0400 Subject: Updated SoV documents Message-ID: <7c7f797d-b5da-7f1e-04f1-e0b3e9d2e745@oracle.com> I've updated the SoV documents, including the new sections on VM model and translation: http://cr.openjdk.java.net/~briangoetz/valhalla/sov/01-background.html From forax at univ-mlv.fr Fri Mar 27 20:18:14 2020 From: forax at univ-mlv.fr (Remi Forax) Date: Fri, 27 Mar 2020 21:18:14 +0100 (CET) Subject: Updated SoV documents In-Reply-To: <7c7f797d-b5da-7f1e-04f1-e0b3e9d2e745@oracle.com> References: <7c7f797d-b5da-7f1e-04f1-e0b3e9d2e745@oracle.com> Message-ID: <1151953289.1509162.1585340294082.JavaMail.zimbra@u-pem.fr> > De: "Brian Goetz" > ?: "valhalla-spec-experts" > Envoy?: Vendredi 27 Mars 2020 20:59:38 > Objet: Updated SoV documents > I've updated the SoV documents, including the new sections on VM model and > translation: > [ http://cr.openjdk.java.net/~briangoetz/valhalla/sov/01-background.html | > http://cr.openjdk.java.net/~briangoetz/valhalla/sov/01-background.html ] Inline classes: "cannot be layout-polymorphic", given they can be parametrized and the type argument being itself an inline type, they can. "or multiple return." -> multiple return value ? regards, R?mi