From Tobi_Ajila at ca.ibm.com Mon Jan 13 21:44:22 2020 From: Tobi_Ajila at ca.ibm.com (Tobi Ajila) Date: Mon, 13 Jan 2020 16:44:22 -0500 Subject: atomicity for value types In-Reply-To: <55A8853E-AFF4-4CDB-A963-3C6E73D0859A@oracle.com> References: <55A8853E-AFF4-4CDB-A963-3C6E73D0859A@oracle.com> Message-ID: Hi John Given that inline types can be flattened there is a possibility that data races will occur in places where users were not expecting it before. So your `__AlwaysAtomic` modifier is a necessary tool as the existing spec will only enforce atomicity for 32bit primitives and references. I just want to confirm if the intention of the __AlwaysAtomic bit on an inline class is only to ensure atomic reads and writes of inline types and that there are no happens-before ordering expectations as there are with the existing volatile modifier on fields. For example: ``` __AlwaysAtomic inline class Long256 { long v1, v2, v3 ,v4; ? } class Example { Long256 bigLong; int x; int y; void method() { Long256 newLong = new Long256(1, 2, 3, 4); x = 1; //compiler is still free to re-order write to bigLong with respect //to writes to x and y, but the write to bigLong must be done atomically bigLong = newLong; y = 2; } } ``` Does this match your expectations? The reason I ask is because of the "Protection is ?as if? each field were volatile" wording in your previous note. Does this only speak to the atomicity properties of the volatile modifier? Or do you intend further constraints? Regards, --Tobi "valhalla-spec-experts" wrote on 2019/12/18 08:46:42 PM: > From: John Rose > To: valhalla-spec-experts > Date: 2019/12/18 08:47 PM > Subject: [EXTERNAL] atomicity for value types > Sent by: "valhalla-spec-experts" bounces at openjdk.java.net> > > In a nutshell, here?s a proposal for value type atomicity: > > - Define a contextual keyword ?alwaysatomic" (working title ?__AlwaysAtomic?). > - It can only occur with ?inline? in class declaration. > - All instances of the given inline class are protected against races. > - Protection is ?as if? each field were volatile, ?and the same? for > array elements. > - In the class file the ACC_VOLATILE bit is used (0x0040) to record > the keyword. > - This bit does not necessarily disable flattening; if the JVM can > get away with flattening it should. > - The JVM can get away with flattening such values on stack, in > registers, and perhaps in final heap variables. > - The JVM can get away with flattening such values if they are > ?naturally atomic?, meaning they can be wholly loaded or stored in > one (atomic) hardware instruction. > > More details to follow. Here?s a backgrounder I wrote a while ago: > > https://urldefense.proofpoint.com/v2/url? > u=http-3A__cr.openjdk.java.net_-7Ejrose_oblog_value-2Dtearing.html&d=DwIFaQ&c=jf_iaSHvJObTbx- > siA1ZOg&r=erClOruSa3K4FS7XawcTd7k9ZbtVLiryTZ1WIpneMMg&m=9WXy2DpynXX2sj1FbCiuW127ablyOD_EN13- > aS4ug04&s=dhRZz0Da6RYg45c_b-x6gFBP0sqXC1VtTWP--BDHMS4&e= > > ? John > > From john.r.rose at oracle.com Mon Jan 13 22:03:35 2020 From: john.r.rose at oracle.com (John Rose) Date: Mon, 13 Jan 2020 14:03:35 -0800 Subject: atomicity for value types In-Reply-To: References: <55A8853E-AFF4-4CDB-A963-3C6E73D0859A@oracle.com> Message-ID: <4CDFA003-CC9B-4B20-8AA4-5D9377F713D6@oracle.com> On Jan 13, 2020, at 1:44 PM, Tobi Ajila wrote: > > Hi John > > Given that inline types can be flattened there is a possibility that data races will occur in places where users were not expecting it before. So your `__AlwaysAtomic` modifier is a necessary tool as the existing spec will only enforce atomicity for 32bit primitives and references. I just want to confirm if the intention of the __AlwaysAtomic bit on an inline class is only to ensure atomic reads and writes of inline types and that there are no happens-before ordering expectations as there are with the existing volatile modifier on fields. Confirmed; thanks for taking the time to raise the question clearly. It really isn?t ?always volatile?; that would be a different and much less useful feature. > For example: > > ``` > __AlwaysAtomic inline class Long256 { long v1, v2, v3 ,v4; ? } > > class Example { > Long256 bigLong; > int x; > int y; > > void method() { > Long256 newLong = new Long256(1, 2, 3, 4); > > x = 1; > > //compiler is still free to re-order write to bigLong with respect > //to writes to x and y, but the write to bigLong must be done atomically > bigLong = newLong; > > y = 2; > } > } > ``` > > Does this match your expectations? Yes, it does. > The reason I ask is because of the "Protection is ?as if? each field were volatile" wording in your previous note. Does this only speak to the atomicity properties of the volatile modifier? Or do you intend further constraints? No further constraints beyond simple atomicity of the individual load or store. In particular no new ordering constraints with other loads or stores. The only special atomicity properties of volatile I?m appealing to are those which apply to long and double. Those are the properties I am seeking to extend to value types, both those marked ?volatile? at the use site of the type, and those marked ?alwaysatomic? at the declaration site of the type. But now that you ask? there are *old* ordering constraints which are relevant. I expect, because an inline type?s fields are always final, that storing an inline value containing a pointer to a new object will safely publish that new object. This rule in the JMM may need to be clarified. In effect, if an inline object contains a pointer, storing it should include a previous store-store ordering constraint, or some other implementation of the JMM ?freeze? operation at the end of the inline?s constructor. Make sense? ? John P.S. After writing unit tests for ?alwaysatomic? I found tearing race conditions in HotSpot which were wrong for all inline types, and not just ?alwaysatomic?. In particular, if the JVM ever secretly buffers a value onto the heap, it should issue a store-store barrier before publishing the secret reference. This may happen, for example, when an inline value is stored in an Object variable. I?m mentioning this in case you have a similar issue in J9. We had enough complicated paths in the HotSpot prototype that in some cases the store-store barrier was not being emitted, causing wrong execution. See also this thread about surprise tearing, and why it?s wrong: http://mail.openjdk.java.net/pipermail/valhalla-dev/2020-January/006706.html From Tobi_Ajila at ca.ibm.com Tue Jan 14 16:59:30 2020 From: Tobi_Ajila at ca.ibm.com (Tobi Ajila) Date: Tue, 14 Jan 2020 11:59:30 -0500 Subject: atomicity for value types In-Reply-To: <4CDFA003-CC9B-4B20-8AA4-5D9377F713D6@oracle.com> References: <55A8853E-AFF4-4CDB-A963-3C6E73D0859A@oracle.com> <4CDFA003-CC9B-4B20-8AA4-5D9377F713D6@oracle.com> Message-ID: > The only special atomicity properties of volatile I?m > appealing to are those which apply to long and double. Thanks for confirming that. > In effect, if an inline object contains a pointer, > storing it should include a previous store-store ordering > constraint, or some other implementation of the JMM > ?freeze? operation at the end of the inline?s constructor. Given the LW2 spec allows withfield to be used anywhere in the nest, an inline-type containing a reference could be constructed outside of the factory. Should the JMM ?freeze? semantics additionally apply to the withfield bytecode? --Tobi > From: John Rose > To: Tobi Ajila > Cc: valhalla-spec-experts > Date: 2020/01/13 05:03 PM > Subject: [EXTERNAL] Re: atomicity for value types > > On Jan 13, 2020, at 1:44 PM, Tobi Ajila wrote: > > > > Hi John > > > > Given that inline types can be flattened there is a possibility > that data races will occur in places where users were not expecting > it before. So your `__AlwaysAtomic` modifier is a necessary tool as > the existing spec will only enforce atomicity for 32bit primitives > and references. I just want to confirm if the intention of the > __AlwaysAtomic bit on an inline class is only to ensure atomic reads > and writes of inline types and that there are no happens-before > ordering expectations as there are with the existing volatile > modifier on fields. > > Confirmed; thanks for taking the time to raise the question clearly. > > It really isn?t ?always volatile?; that would be a different and much less > useful feature. > > > For example: > > > > ``` > > __AlwaysAtomic inline class Long256 { long v1, v2, v3 ,v4; ? } > > > > class Example { > > Long256 bigLong; > > int x; > > int y; > > > > void method() { > > Long256 newLong = new Long256(1, 2, 3, 4); > > > > x = 1; > > > > //compiler is still free to re-order write to bigLong with respect > > //to writes to x and y, but the write to bigLong must be done atomically > > bigLong = newLong; > > > > y = 2; > > } > > } > > ``` > > > > Does this match your expectations? > > Yes, it does. > > > The reason I ask is because of the "Protection is ?as if? each > field were volatile" wording in your previous note. Does this only > speak to the atomicity properties of the volatile modifier? Or do > you intend further constraints? > > No further constraints beyond simple atomicity of the individual > load or store. In particular no new ordering constraints with other > loads or stores. > > The only special atomicity properties of volatile I?m appealing to > are those which apply to long and double. Those are the properties > I am seeking to extend to value types, both those marked ?volatile? > at the use site of the type, and those marked ?alwaysatomic? at the > declaration site of the type. > > But now that you ask? there are *old* ordering constraints which > are relevant. > > I expect, because an inline type?s fields are always final, that > storing an inline value containing a pointer to a new object will > safely publish that new object. This rule in the JMM may need > to be clarified. In effect, if an inline object contains a pointer, > storing it should include a previous store-store ordering > constraint, or some other implementation of the JMM > ?freeze? operation at the end of the inline?s constructor. > > Make sense? > > ? John > > P.S. After writing unit tests for ?alwaysatomic? I found tearing > race conditions in HotSpot which were wrong for all inline types, > and not just ?alwaysatomic?. In particular, if the JVM ever secretly > buffers a value onto the heap, it should issue a store-store barrier > before publishing the secret reference. This may happen, for example, > when an inline value is stored in an Object variable. I?m mentioning > this in case you have a similar issue in J9. We had enough complicated > paths in the HotSpot prototype that in some cases the store-store > barrier was not being emitted, causing wrong execution. > > See also this thread about surprise tearing, and why it?s wrong: > > https://urldefense.proofpoint.com/v2/url? > u=http-3A__mail.openjdk.java.net_pipermail_valhalla-2Ddev_2020-2DJanuary_006706.html&d=DwIFaQ&c=jf_iaSHvJObTbx- > siA1ZOg&r=erClOruSa3K4FS7XawcTd7k9ZbtVLiryTZ1WIpneMMg&m=uSBdbgpyj81Z9PT43WizJufMTVJq- > YMA3jDRYV1Fpr0&s=X9LNJxyH8Z8b1-Kfti4O4yQB-cmMxA3PwXIPvhoP55o&e= From dl at cs.oswego.edu Tue Jan 14 17:11:42 2020 From: dl at cs.oswego.edu (Doug Lea) Date: Tue, 14 Jan 2020 12:11:42 -0500 Subject: atomicity for value types In-Reply-To: References: <55A8853E-AFF4-4CDB-A963-3C6E73D0859A@oracle.com> Message-ID: <5bee20d4-7425-f0c2-5b07-07341d1f295f@cs.oswego.edu> On 1/13/20 4:44 PM, Tobi Ajila wrote: > Hi John > > Given that inline types can be flattened there is a possibility that > data races will occur in places where users were not expecting it > before. So your `__AlwaysAtomic` modifier is a necessary tool as the > existing spec will only enforce atomicity for 32bit primitives and > references. I just want to confirm if the intention of the > __AlwaysAtomic bit on an inline class is only to ensure atomic reads and > writes of inline types and that there are no happens-before ordering > expectations as there are with the existing volatile modifier on fields. > In which case "__AlwaysOpaque" would be a more accurate term. -Doug > For example: > > ``` > __AlwaysAtomic inline class Long256 { long v1, v2, v3 ,v4; ? } > > class Example { > Long256 bigLong; > int x; > int y; > > void method() { > Long256 newLong = new Long256(1, 2, 3, 4); > > x = 1; > > > //compiler is still free to re-order write to bigLong with respect > //to writes to x and y, but the write to bigLong must be done atomically > bigLong = newLong; > > y = 2; > } > } > ``` > > Does this match your expectations? > > The reason I ask is because of the "Protection is ?as if? each field > were volatile" wording in your previous note. Does this only speak to > the atomicity properties of the volatile modifier? Or do you intend > further constraints? > > Regards, > --Tobi > > > "valhalla-spec-experts" > wrote on 2019/12/18 08:46:42 PM: > >> From: John Rose >> To: valhalla-spec-experts >> Date: 2019/12/18 08:47 PM >> Subject: [EXTERNAL] atomicity for value types >> Sent by: "valhalla-spec-experts" > bounces at openjdk.java.net> >> >> In a nutshell, here?s a proposal for value type atomicity: >> >> - Define a contextual keyword ?alwaysatomic" (working title > ?__AlwaysAtomic?). >> - It can only occur with ?inline? in class declaration. >> - All instances of the given inline class are protected against races. >> - Protection is ?as if? each field were volatile, ?and the same? for >> array elements. >> - In the class file the ACC_VOLATILE bit is used (0x0040) to record >> the keyword. >> - This bit does not necessarily disable flattening; if the JVM can >> get away with flattening it should. >> - The JVM can get away with flattening such values on stack, in >> registers, and perhaps in final heap variables. >> - The JVM can get away with flattening such values if they are >> ?naturally atomic?, meaning they can be wholly loaded or stored in >> one (atomic) hardware instruction. >> >> More details to follow. ?Here?s a backgrounder I wrote a while ago: >> >> INVALID URI REMOVED >> > u=http-3A__cr.openjdk.java.net_-7Ejrose_oblog_value-2Dtearing.html&d=DwIFaQ&c=jf_iaSHvJObTbx- >> > siA1ZOg&r=erClOruSa3K4FS7XawcTd7k9ZbtVLiryTZ1WIpneMMg&m=9WXy2DpynXX2sj1FbCiuW127ablyOD_EN13- >> aS4ug04&s=dhRZz0Da6RYg45c_b-x6gFBP0sqXC1VtTWP--BDHMS4&e= >> >> ? John >> >> > From john.r.rose at oracle.com Tue Jan 14 20:43:28 2020 From: john.r.rose at oracle.com (John Rose) Date: Tue, 14 Jan 2020 12:43:28 -0800 Subject: atomicity for value types In-Reply-To: <5bee20d4-7425-f0c2-5b07-07341d1f295f@cs.oswego.edu> References: <55A8853E-AFF4-4CDB-A963-3C6E73D0859A@oracle.com> <5bee20d4-7425-f0c2-5b07-07341d1f295f@cs.oswego.edu> Message-ID: On Jan 14, 2020, at 9:11 AM, Doug Lea
wrote: > > On 1/13/20 4:44 PM, Tobi Ajila wrote: >> Hi John >> >> Given that inline types can be flattened there is a possibility that >> data races will occur in places where users were not expecting it >> before. So your `__AlwaysAtomic` modifier is a necessary tool as the >> existing spec will only enforce atomicity for 32bit primitives and >> references. I just want to confirm if the intention of the >> __AlwaysAtomic bit on an inline class is only to ensure atomic reads and >> writes of inline types and that there are no happens-before ordering >> expectations as there are with the existing volatile modifier on fields. >> > > In which case "__AlwaysOpaque" would be a more accurate term. Very interesting! I guess this is the most relevant definition of opaque: http://gee.cs.oswego.edu/dl/html/j9mm.html#opaquesec Doug, in honor of one of your pet expressions, I would have preferred to spell this keyword ?not-too-tearable?, but that?s truly an opaque phrase. OK, so the above document defines a nice linear scale of four memory access modes, ordered from weak to strong: Plain, Opaque, Release/Acquire, and Volatile. ?Any guaranteed property of a weaker mode, plus more, holds for a stronger mode.? For a JIT writer, this means stronger modes will require additional ordering constraints, in IR and/or as hardware fence instructions, and perhaps also stronger memory access instructions. In the worst case (which we may see with inline types) library calls may be required to perform some accesses ? plus the space overhead of control variables for things like seq-locks or mutexes. The effect of the Plain mode on atomicity is described here: > Additionally, while Java Plain accesses to int, char, short, float, byte, and reference types are primitively bitwise atomic, for the others, long, double, as well as compound Value Types planned for future JDK releases, it is possible for a racy read to return a value with some bits from a write by one thread, and other bits from another, with unusable results. Then, Opaque mode tightens up the behavior of Plain mode by adding Bitwise Atomicity (what I want here), plus three more guarantees: Per-variable antecedence acyclicity, Coherence, and Progress. The document then suggests that these three more guarantees won?t inconvenience the JIT writer: > Opaque mode does not directly impose any ordering constraints with respect to other variables beyond Plain mode. But I think there will might be inconveniences. Our current prototype doesn?t mess with STM or HTM, but just buffers every new value (under always-atomic or volatile) into a freshly allocated heap node, issues a Release fence, and publishes the node reference into the relevant 64-bit variable. The node reference itself is stored in Plain (Relaxed) mode, not Opaque or Release mode, and subsequent loads are also relaxed (no IR or HW fences). What we are doing with this buffering trick is meeting the requirements of atomicity by using the previously-specified mechanisms for safe publication (of regular identity classes with final instance variables). In order to use this trick correctly we need to ensure that the specified behavior of the always-atomic store does not make additional requirements. When I look at the HotSpot code, I find that, if I were to classify loads and stores of always-atomic as always-Opaque, I would find myself adding more IR constraints than if I simply use the trick of buffering for safe publication. Maybe HotSpot is doing some overkill on Opaque mode (see notes below for evidence of that) but I can?t help thinking that at least the requirement of Progress (for Opaque) will require the loop optimizer to take special care with always-Opaque variables that it would not have to take with merely always-atomic ones. This is a round-about way of say, ?really Opaque? Why not just atomic?? If I take always-Opaque as the definition I can use a clearly defined category in upcoming JMM revisions (good!) but OTOH I get knock on requirements (slow-downs) from that same category (bad!). It?s not right to say, ?but always-atomic values will *always* be *slow* as well, so quit complaining about lost optimizations?. That?s because the JVM will often pack small always-atomic values into single memory units (64- or 128-bit, whatever the hardware supports with native atomicity). In such cases, Plain order has a real performance benefit relative to Opaque order, yes? So, in the end, I?d like to call it always-atomic, and leave Opaque mode as an additional opt-in for these types. ? John P.S. More background, FTR: Our intention with always-atomic types is to guarantee a modest extension of type safety, that combinations of field values which appear from memory reads will never be different from combinations that have been created by constructor code (or else they are the default combination). This appeal to constructors extends type safety in the sense that the inline class is able to exclude from its value set some of the composite values that would otherwise appear if the composite were an unconstrained tuple type (aka. direct product). If the class has the power to absolutely constrain its value set in this way, any type safety properties that depend on exclusion of values can be proven, while if tearing is allowed, type safety proofs must confront all values physically possible to the corresponding tuple type. In particular, if an inline type implements a var-handle holding the components of an unsafe addressing mode (Object, long), tearing could introduce arbitrary combinations of (previously stored) Object and long values, breaking delicate type safety invariants. Such inlines need to be marked always-atomic to exclude tearing. This concern is separate from any other control over memory ordering and race exclusion. In particular, the JVM will (by default) freely reorder reads and writes of always-atomic inlines like any other Plain mode operations, as if the inline were a naturally atomic value (like an int or reference). The semantics will be ?as if? the inline value were actually represented as a reference to an all-final box-like object. We call such an object a ?buffer? to distinguish it from a user-visible ?box? or ?wrapper object?. The point is not to always require memory allocations when storing an always-atomic value (though such allocations are a valid tactic). The point is to align atomicity constraints with the safe-publication rules enjoyed by non-inline identity objects, whether or not actual memory buffers are created. In that case, why not just make inline values safe by default, by analogy with safe publication of their (all-final) indirect cousines? The problem is that safe-publication is likely to be more expensive for inlines than for identity objects, so it needs to be an opt-in feature. Hence the very special always-atomic modifier. (Thought exercise: What would always-atomic mean if applied to stateful identity objects? I think it would mean that updates to the object would become transactional, as if the whole object state were a single always-atomic tuple. I suppose every method body would be treated as a transaction, probably under an N readers / 1 writer discipline. As with inlines, such a transaction would be enforced by whatever tricks the JVM could muster, maybe TSX on Intel, or STM, or hidden buffering.) To finish the analogy with naturally atomic types (int, reference), an inline can be accessed in Opaque, Release/Acquire, or Volatile mode by means of appropriate var-handle operations (or the equivalent). Such accesses will be subject to stronger ordering constraints. They will also be atomic whether or not the inline type was declared always-atomic. BTW some code in HotSpot refers to Plain mode as Relaxed. Both the JVM and the Unsafe API work in the expected way with stores that Release and reads that Acquire. Confusingly, other HotSpot code assigns the term RELAXED to Opaque, using UNORDERED for Plain. Naming is hard. Also, the HotSpot code treats RELAXED/Opaque as stronger not weaker than VOLATILE. Not everyone is on the same page yet. So the current state of the HotSpot code, Opaque (aka. RELAXED > VOLATILE) does in fact add IR ordering constraints where Plain mode does not. From john.r.rose at oracle.com Wed Jan 15 00:40:34 2020 From: john.r.rose at oracle.com (John Rose) Date: Tue, 14 Jan 2020 16:40:34 -0800 Subject: atomicity for value types In-Reply-To: <55A8853E-AFF4-4CDB-A963-3C6E73D0859A@oracle.com> References: <55A8853E-AFF4-4CDB-A963-3C6E73D0859A@oracle.com> Message-ID: <14003B2B-981C-4110-82E1-BC8B28B38E71@oracle.com> On Dec 18, 2019, at 5:46 PM, John Rose wrote: > > - Define a contextual keyword ?alwaysatomic" (working title ?__AlwaysAtomic?). I just referred more carefully to the draft JEP on keyword management https://openjdk.java.net/jeps/8223002 and realize that it guides us toward a so-called ?hyphenated contextual keyword? in preference to a ?unitary contextual keyword?. That is, ?always-atomic? is more in keeping with that document than ?alwaysatomic?. I do think this looks more jarring than the unitary keyword: always-atomic inline class Cursor { ? } But, that?s only because it?s an early hyphenated keyword, which nobody is eye-trained on yet. If we believe that hyphenated keywords are the wave of the future, as I do, then we should embrace it, rather than the old-school unitary token ?alwaysatomic?. In the prototype I?m using a temporary (unitary contextual) keyword __AlwaysAtomic, plus a temporary annotation @__alwaysatomic__. In the JVMs the draft of the corresponding modifier bit looks like this: ACC_ALWAYSATOMIC 0x0040 Instances of this inline type are never torn. From forax at univ-mlv.fr Wed Jan 15 00:52:35 2020 From: forax at univ-mlv.fr (Remi Forax) Date: Wed, 15 Jan 2020 01:52:35 +0100 (CET) Subject: atomicity for value types In-Reply-To: <14003B2B-981C-4110-82E1-BC8B28B38E71@oracle.com> References: <55A8853E-AFF4-4CDB-A963-3C6E73D0859A@oracle.com> <14003B2B-981C-4110-82E1-BC8B28B38E71@oracle.com> Message-ID: <338607809.1335934.1579049555795.JavaMail.zimbra@u-pem.fr> In the context of Java, we are already using the term 'atomic', in AtomicInteger, AtomicLong, etc, and in that case the semantics is volatile + atomic operations (at least CAS), so i think using atomic or any keyword derived from it will not help to our users to understand the semantics for an inline class. As Doug said, for a VarHandle, the semantics we want is called opaque, so "opaque" is ok for me. Otherwise, the idea is that you can not cut the loads/stores, so "indivisible" is also ok. R?mi > De: "John Rose" > ?: "valhalla-spec-experts" > Envoy?: Mercredi 15 Janvier 2020 01:40:34 > Objet: Re: atomicity for value types > On Dec 18, 2019, at 5:46 PM, John Rose < [ mailto:john.r.rose at oracle.com | > john.r.rose at oracle.com ] > wrote: >> - Define a contextual keyword ?alwaysatomic" (working title ?__AlwaysAtomic?). > I just referred more carefully to the draft JEP on keyword > management [ https://openjdk.java.net/jeps/8223002 | > https://openjdk.java.net/jeps/8223002 ] and > realize that it guides us toward a so-called ?hyphenated > contextual keyword? in preference to a ?unitary contextual > keyword?. That is, ?always-atomic? is more in keeping with > that document than ?alwaysatomic?. > I do think this looks more jarring than the unitary keyword: > always-atomic inline class Cursor { ? } > But, that?s only because it?s an early hyphenated keyword, > which nobody is eye-trained on yet. If we believe that > hyphenated keywords are the wave of the future, as I do, > then we should embrace it, rather than the old-school > unitary token ?alwaysatomic?. > In the prototype I?m using a temporary (unitary contextual) keyword-ato > __AlwaysAtomic, plus a temporary annotation @__alwaysatomic__. > In the JVMs the draft of the corresponding modifier bit looks like this: > ACC_ALWAYSATOMIC 0x0040 Instances of this inline type are never torn. From john.r.rose at oracle.com Wed Jan 15 01:18:07 2020 From: john.r.rose at oracle.com (John Rose) Date: Tue, 14 Jan 2020 17:18:07 -0800 Subject: atomicity for value types In-Reply-To: <338607809.1335934.1579049555795.JavaMail.zimbra@u-pem.fr> References: <55A8853E-AFF4-4CDB-A963-3C6E73D0859A@oracle.com> <14003B2B-981C-4110-82E1-BC8B28B38E71@oracle.com> <338607809.1335934.1579049555795.JavaMail.zimbra@u-pem.fr> Message-ID: On Jan 14, 2020, at 4:52 PM, Remi Forax wrote: > > In the context of Java, we are already using the term 'atomic', in AtomicInteger, AtomicLong, etc, Even more fundamentally, the term ?atomic? is in the JLS, JVMS, and JMM with the same meaning being proposed here, and *not* subsumed by nor identical with ?volatile?. JMVS 4: > Untyped instructions that manipulate the operand stack must treat values of type long and double as atomic (indivisible). JLS 17.7. Non-Atomic Treatment of double and long: > Writes and reads of volatile long and double values are always atomic? Writes to and reads of references are always atomic? And JMM has more of the same. > and in that case the semantics is volatile + atomic operations (at least CAS), so i think using atomic or any keyword derived from it will not help to our users to understand the semantics for an inline class. So volatile is associated with atomic, but it is not identical. You came up with an interesting example of that association, the AtomicLong API, but it?s just an association. Nobody will be confused. > As Doug said, for a VarHandle, the semantics we want is called opaque, so "opaque" is ok for me. Opaque has meaning only in the JMM (not for the general public) and in that document the term atomic is also more correct. > Otherwise, the idea is that you can not cut the loads/stores, so "indivisible" is also ok. The JVMS uses ?indivisible? (see above) to amplify the term ?atomic?, but the primary term is ?atomic?. ? John From dl at cs.oswego.edu Wed Jan 15 12:50:26 2020 From: dl at cs.oswego.edu (Doug Lea) Date: Wed, 15 Jan 2020 07:50:26 -0500 Subject: atomicity for value types In-Reply-To: References: <55A8853E-AFF4-4CDB-A963-3C6E73D0859A@oracle.com> <5bee20d4-7425-f0c2-5b07-07341d1f295f@cs.oswego.edu> Message-ID: <808a6683-037d-bafd-fb62-992c7cff09cb@cs.oswego.edu> On 1/14/20 3:43 PM, John Rose wrote: > On Jan 14, 2020, at 9:11 AM, Doug Lea
> wrote: >> In which case "__AlwaysOpaque" would be a more accurate term. > > Very interesting! ?I guess this is the most relevant definition of opaque: > ? http://gee.cs.oswego.edu/dl/html/j9mm.html#opaquesec > > Doug, in honor of one of your pet expressions, I would have > preferred to spell this keyword ?not-too-tearable?, but > that?s truly an opaque phrase. OK; I was concerned that your proposed definition was too strong, but weaker is fine, because optionally stronger modes can then be accessed via VarHandles. The term used in JDK9+ memory specs is "bitwise-atomic", which is one part of Opaque mode (also holding for plain mode <=32bit and refs). But it is possible and desirable to separate it for sake of Record types. Perhaps a better term is "integral" (better than non-tearable). But if we want hyphen-friendly modifiers, just "bitwise-atomic" works (or __bitwiseAtomic as standin until adopted). As in: bitwise-atomic inline class Long256 { long v1, v2, v3 ,v4; ? } (Aside: should "bitwise-atomic long" also be a valid type?) -Doug From martinrb at google.com Wed Jan 15 13:49:29 2020 From: martinrb at google.com (Martin Buchholz) Date: Wed, 15 Jan 2020 05:49:29 -0800 Subject: atomicity for value types In-Reply-To: <808a6683-037d-bafd-fb62-992c7cff09cb@cs.oswego.edu> References: <55A8853E-AFF4-4CDB-A963-3C6E73D0859A@oracle.com> <5bee20d4-7425-f0c2-5b07-07341d1f295f@cs.oswego.edu> <808a6683-037d-bafd-fb62-992c7cff09cb@cs.oswego.edu> Message-ID: I've always felt that it's better to have concurrency properties declared as part of the type, guided by C++ atomic<>, and VarHandle was a step away from that (towards concurrency "assembly language"). It's more difficult in Java where there are no zero-cost user abstractions (yet!). I'm worried about a hardware dependent performance cliff when the size of an object grows beyond some word size and locks need to be used. Java still needs that revised memory model, but it's very difficult to get right. From forax at univ-mlv.fr Wed Jan 15 14:26:21 2020 From: forax at univ-mlv.fr (forax at univ-mlv.fr) Date: Wed, 15 Jan 2020 15:26:21 +0100 (CET) Subject: atomicity for value types In-Reply-To: References: <55A8853E-AFF4-4CDB-A963-3C6E73D0859A@oracle.com> <14003B2B-981C-4110-82E1-BC8B28B38E71@oracle.com> <338607809.1335934.1579049555795.JavaMail.zimbra@u-pem.fr> Message-ID: <1770998619.1720982.1579098381167.JavaMail.zimbra@u-pem.fr> ----- Mail original ----- > De: "John Rose" > ?: "Remi Forax" > Cc: "valhalla-spec-experts" > Envoy?: Mercredi 15 Janvier 2020 02:18:07 > Objet: Re: atomicity for value types > On Jan 14, 2020, at 4:52 PM, Remi Forax wrote: >> >> In the context of Java, we are already using the term 'atomic', in >> AtomicInteger, AtomicLong, etc, > > Even more fundamentally, the term ?atomic? is in the JLS, JVMS, and JMM > with the same meaning being proposed here, and *not* subsumed by nor identical > with ?volatile?. > > JMVS 4: > >> Untyped instructions that manipulate the operand stack must treat values of type >> long and double as atomic (indivisible). > > JLS 17.7. Non-Atomic Treatment of double and long: > >> Writes and reads of volatile long and double values are always atomic? Writes to >> and reads of references are always atomic? > > And JMM has more of the same. > >> and in that case the semantics is volatile + atomic operations (at least CAS), >> so i think using atomic or any keyword derived from it will not help to our >> users to understand the semantics for an inline class. > > So volatile is associated with atomic, but it is not identical. > You came up with an interesting example of that association, > the AtomicLong API, but it?s just an association. Nobody will be > confused. I'm confused :) > >> As Doug said, for a VarHandle, the semantics we want is called opaque, so >> "opaque" is ok for me. > > Opaque has meaning only in the JMM (not for the general public) > and in that document the term atomic is also more correct. > >> Otherwise, the idea is that you can not cut the loads/stores, so "indivisible" >> is also ok. > > The JVMS uses ?indivisible? (see above) to amplify the term ?atomic?, > but the primary term is ?atomic?. > Do you agree that the semantics we want for an inline type that is non teareable and the semantics we want for a value with locked operations (locked like in LADD) are different ? I've chosen "indivisible" because is the latin equivalent of atomic (which comes from the greak leanguage), but that's not the point, the point is that we need two terms given that there are two semantics. Actually the JDK (package java.util.concurrent.atomic) and the JVMS/JLS disagree on what atomic means, this should be fixed too. But it's a collateral problem. Furthermore, at some point in the future, we will want to propose an inline generics that provides locked operations on any values, the natural name for this inline class is "Atomic", an Atomic being the unmutable, zero cost equivalent of an AtomicLong. This will muddy the water even more. > ? John R?mi From frederic.parain at oracle.com Wed Jan 29 17:57:36 2020 From: frederic.parain at oracle.com (Frederic Parain) Date: Wed, 29 Jan 2020 12:57:36 -0500 Subject: Valhalla EG 20200129 Message-ID: <391D0796-33A6-424A-9D05-3FF4F69372F2@oracle.com> # Valhalla EG Meeting 20200129 Dan S., Remi, Brian, Dan (IBM), Tobi (IBM) Brian: language side implementation: compiler support to inject InlineObject/IdentityObject super-types at compilation time some issues with reflection code assuming type hierarchy Remi: Annotation of j.l.Object Brian: j.l.Object is not annotated by either InlineObject or IdentityObject Remi: new Object()? Brian: new Object() will be the instanciation of an abtract class subclass of j.l.Object push people to move away from this construct with new way to get an Object. Remi: could be in the IdentityObject interface Brian: working on reference projection as an interface or an abstract class possible update next week, working on simplification would lead to rewrite of "State of Valhalla" Remi: did analysis of static fields set at VM startup but not read (bytecode level analysis) Brian: Lazy static: push people to initalize at time of declaration but issue with checked exception => reasons why people at initializing fields in big static initializers we need a construct in the language to declare a lazy static with shared throw clause for all lazy static fields Remi: Foreign Memory Access API: issue with VarHandles and checked exceptions Talk at Brest JUG: no questions about Records, but a lot of questions about instanceof lot of confusion between inline types and records Brian: arithmetic benchmarks being developped mixed results HashMap: optimized for many years lot of corner cases Remi: did some experiments with HashMap saw benefits only if both key and values are in-lined Brian: issue with big flattened values => lot of data to be moved need to educate people about algorithms/designs that work or don't work with inline types Remi: references Google's fluent API to re-work abstractions Brian: hope that using inline types for lambdas would help escape analysis getting it right Dan (IBM): is there a JDK release targeted for Valhalla? Brian: too early to say VM work is consolidating language work still needs significant work before having a road-map first release won't have all the features but have to have further additions in mind next Valhalla off-site probably during spring Remi: John wants to move to a specialized generics prototype Fred: start with a simpler specialized generics model so language and VM teams can work in parallel: VM team extending VM data structures (constant pool patching) language team working on full specialization model Brian: retrofitting of Integer: seemed impossible, but now seems more feasible