From daniel.smith at oracle.com Wed Jan 5 23:37:09 2022 From: daniel.smith at oracle.com (Dan Smith) Date: Wed, 5 Jan 2022 23:37:09 +0000 Subject: Updated State of Valhalla documents In-Reply-To: <313972565.1229854.1640289483686.JavaMail.zimbra@u-pem.fr> References: <09EED588-7A6E-4BB8-8DCA-08C29F4E3D73@oracle.com> <1471584940.1211017.1640284516318.JavaMail.zimbra@u-pem.fr> <112398AD-D910-4AF4-8644-844A07DE6539@oracle.com> <394037657.1216754.1640287568639.JavaMail.zimbra@u-pem.fr> <056021F6-4BDF-43C8-A3DC-C9D2B064FC59@oracle.com> <313972565.1229854.1640289483686.JavaMail.zimbra@u-pem.fr> Message-ID: > On Dec 23, 2021, at 12:58 PM, forax at univ-mlv.fr wrote: > > But for Java, i would argue that the model is more > we have either reference objects or primitives, for reference objects you have those with identity and those without identity, > hence "primitive" being a top-level kind while "value" (or a better term) being a modifier. I don't want to get too in the weeds on syntax (even though, yes, it does help convey the underlying model!). The change you propose is, indeed, a possibility that is still on the table. But: it's really important to understand that, in the proposed model, primitive values, identity objects, and value objects *all* belong to classes. That's where they get their members, via the normal rules about class membership. A primitive value is an instance of a class, even though it is not an object. Whether we use the syntax 'c l a s s' in the primitive declaration, the thing being declared is a class. Just like the thing being declared with 'e n u m' is a class. From forax at univ-mlv.fr Thu Jan 6 00:14:36 2022 From: forax at univ-mlv.fr (forax at univ-mlv.fr) Date: Thu, 6 Jan 2022 01:14:36 +0100 (CET) Subject: Updated State of Valhalla documents In-Reply-To: References: <09EED588-7A6E-4BB8-8DCA-08C29F4E3D73@oracle.com> <1471584940.1211017.1640284516318.JavaMail.zimbra@u-pem.fr> <112398AD-D910-4AF4-8644-844A07DE6539@oracle.com> <394037657.1216754.1640287568639.JavaMail.zimbra@u-pem.fr> <056021F6-4BDF-43C8-A3DC-C9D2B064FC59@oracle.com> <313972565.1229854.1640289483686.JavaMail.zimbra@u-pem.fr> Message-ID: <24868508.6004197.1641428076934.JavaMail.zimbra@u-pem.fr> ----- Original Message ----- > From: "daniel smith" > To: "Remi Forax" > Cc: "valhalla-spec-experts" > Sent: Thursday, January 6, 2022 12:37:09 AM > Subject: Re: Updated State of Valhalla documents >> On Dec 23, 2021, at 12:58 PM, forax at univ-mlv.fr wrote: >> >> But for Java, i would argue that the model is more >> we have either reference objects or primitives, for reference objects you have >> those with identity and those without identity, >> hence "primitive" being a top-level kind while "value" (or a better term) being >> a modifier. > > I don't want to get too in the weeds on syntax (even though, yes, it does help > convey the underlying model!). The change you propose is, indeed, a possibility > that is still on the table. > > But: it's really important to understand that, in the proposed model, primitive > values, identity objects, and value objects *all* belong to classes. That's > where they get their members, via the normal rules about class membership. A > primitive value is an instance of a class, even though it is not an object. > > Whether we use the syntax 'c l a s s' in the primitive declaration, the thing > being declared is a class. Just like the thing being declared with 'e n u m' is > a class. yes, for the VM, a lambda, a record or an enum are all classes, even if in the syntax the keyword "class" is not used. A primitive (B3) does not provide proper encapsulation unlike a classical Java class (the one spelt "class" in the language), because - the default value (the fields fill with zeroes) is always a valid value - a primitive is tearable I'm trying to find ways to convey that semantics through the syntax, because most users, at least at the beginning, derive the semantics from the syntax, - Not using "primitive class" but only "primitive" is a possible step. - Forcing to have a default constructor automatically generated with the same visiblity as the class that can not be overridden (apart to add javadoc) by the user is another possible step. As another example, Anderson Vasconcelos Pires proposed on the dev mailing list to not use "new" to create a primitive object, i believe because a primitive object does not require a heap allocation, so it may make sense to not use "new" the same way we do not use "new" in front of a lambda. But it's a counter example, because we know that if primitive can be created without new people will abuse of it and declare primitive classes where they should not, just to avoid 3 keystrokes. regards, R?mi From daniel.smith at oracle.com Thu Jan 6 00:44:37 2022 From: daniel.smith at oracle.com (Dan Smith) Date: Thu, 6 Jan 2022 00:44:37 +0000 Subject: Updated State of Valhalla documents In-Reply-To: <24868508.6004197.1641428076934.JavaMail.zimbra@u-pem.fr> References: <09EED588-7A6E-4BB8-8DCA-08C29F4E3D73@oracle.com> <1471584940.1211017.1640284516318.JavaMail.zimbra@u-pem.fr> <112398AD-D910-4AF4-8644-844A07DE6539@oracle.com> <394037657.1216754.1640287568639.JavaMail.zimbra@u-pem.fr> <056021F6-4BDF-43C8-A3DC-C9D2B064FC59@oracle.com> <313972565.1229854.1640289483686.JavaMail.zimbra@u-pem.fr> <24868508.6004197.1641428076934.JavaMail.zimbra@u-pem.fr> Message-ID: <4A7F0325-CE74-4BC8-BD5C-15C59B8C9637@oracle.com> > On Jan 5, 2022, at 5:14 PM, forax at univ-mlv.fr wrote: > >> But: it's really important to understand that, in the proposed model, primitive >> values, identity objects, and value objects *all* belong to classes. > > yes, > for the VM, a lambda, a record or an enum are all classes, even if in the syntax the keyword "class" is not used. Not talking about the VM. I'm talking about the language model. > A primitive (B3) does not provide proper encapsulation unlike a classical Java class (the one spelt "class" in the language), You should say "object" here, not "class". Primitive values have classes, even though they are not objects. From john.r.rose at oracle.com Thu Jan 6 03:53:28 2022 From: john.r.rose at oracle.com (John Rose) Date: Thu, 6 Jan 2022 03:53:28 +0000 Subject: Updated State of Valhalla documents In-Reply-To: <4A7F0325-CE74-4BC8-BD5C-15C59B8C9637@oracle.com> References: <09EED588-7A6E-4BB8-8DCA-08C29F4E3D73@oracle.com> <1471584940.1211017.1640284516318.JavaMail.zimbra@u-pem.fr> <112398AD-D910-4AF4-8644-844A07DE6539@oracle.com> <394037657.1216754.1640287568639.JavaMail.zimbra@u-pem.fr> <056021F6-4BDF-43C8-A3DC-C9D2B064FC59@oracle.com> <313972565.1229854.1640289483686.JavaMail.zimbra@u-pem.fr> <24868508.6004197.1641428076934.JavaMail.zimbra@u-pem.fr> <4A7F0325-CE74-4BC8-BD5C-15C59B8C9637@oracle.com> Message-ID: <3C817B4C-E943-46B9-9C3C-FE0D4D8861CA@oracle.com> > On Jan 5, 2022, at 4:45 PM, Dan Smith wrote: > > Not talking about the VM. I'm talking about the language model. > >> A primitive (B3) does not provide proper encapsulation unlike a classical Java class (the one spelt "class" in the language), > > You should say "object" here, not "class". Primitive values have classes, even though they are not objects. Yes. And what?s more, Remi?s point about encapsulation is weak, because we can (possibly) assume that every author of a primitive class has checked those boxes off, saying that all-zero default is a valid value and tearing is acceptable. There are plenty of Java B1 classes today that are designed with such weaknesses. Class abstractions come in various strengths as selected by each class?s author. Selecting primitive for a class forces the author to gives up some abstraction but keeps most abstraction decisions intact. Having the required hardwired null-arg constructor syntactixally present is an interesting idea to ensure that the author has explicitly ?checked the box? about the default value. Not sure it?s worth it though. From forax at univ-mlv.fr Thu Jan 6 18:40:02 2022 From: forax at univ-mlv.fr (forax at univ-mlv.fr) Date: Thu, 6 Jan 2022 19:40:02 +0100 (CET) Subject: Updated State of Valhalla documents In-Reply-To: <3C817B4C-E943-46B9-9C3C-FE0D4D8861CA@oracle.com> References: <09EED588-7A6E-4BB8-8DCA-08C29F4E3D73@oracle.com> <394037657.1216754.1640287568639.JavaMail.zimbra@u-pem.fr> <056021F6-4BDF-43C8-A3DC-C9D2B064FC59@oracle.com> <313972565.1229854.1640289483686.JavaMail.zimbra@u-pem.fr> <24868508.6004197.1641428076934.JavaMail.zimbra@u-pem.fr> <4A7F0325-CE74-4BC8-BD5C-15C59B8C9637@oracle.com> <3C817B4C-E943-46B9-9C3C-FE0D4D8861CA@oracle.com> Message-ID: <2013584012.6666840.1641494402447.JavaMail.zimbra@u-pem.fr> ----- Original Message ----- > From: "John Rose" > To: "daniel smith" > Cc: "Remi Forax" , "valhalla-spec-experts" > Sent: Thursday, January 6, 2022 4:53:28 AM > Subject: Re: Updated State of Valhalla documents >> On Jan 5, 2022, at 4:45 PM, Dan Smith wrote: >> >> Not talking about the VM. I'm talking about the language model. >> >>> A primitive (B3) does not provide proper encapsulation unlike a classical Java >>> class (the one spelt "class" in the language), >> >> You should say "object" here, not "class". Primitive values have classes, even >> though they are not objects. > > Yes. And what?s more, Remi?s point about encapsulation is weak, because we can > (possibly) assume that every author of a primitive class has checked those > boxes off, saying that all-zero default is a valid value and tearing is > acceptable. There are plenty of Java B1 classes today that are designed with > such weaknesses. Class abstractions come in various strengths as selected by > each class?s author. Selecting primitive for a class forces the author to gives > up some abstraction but keeps most abstraction decisions intact. Being a primitive weaken the encapsulation, but your are right that it's not a all or nothing thing. > > Having the required hardwired null-arg constructor syntactically present is an > interesting idea to ensure that the author has explicitly ?checked the box? > about the default value. Not sure it?s worth it though. If we want to check the other box, tearing, at least partially, i suppose that creating a VarHandle on a non volatile primitive class should be rejected too. R?mi From forax at univ-mlv.fr Thu Jan 6 18:50:54 2022 From: forax at univ-mlv.fr (Remi Forax) Date: Thu, 6 Jan 2022 19:50:54 +0100 (CET) Subject: Why do we need .ref class for primtive class ? Message-ID: <1025656701.6673192.1641495054893.JavaMail.zimbra@u-pem.fr> It just occurs to me that while ACC_VALUE is a bit that change the runtime semantics, something the VM should take care of, ACC_PRIMITIVE is not a bit that change the runtime semantics, only the javac translation strategy, javac emits Q-types instead of L-type + the Preload attribute. If value classes and primitive classes are equivalent at runtime, why do we need to generate the .ref interface/abstract class ? We can use L-type instead. R?mi From forax at univ-mlv.fr Thu Jan 6 19:24:37 2022 From: forax at univ-mlv.fr (Remi Forax) Date: Thu, 6 Jan 2022 20:24:37 +0100 (CET) Subject: Why do we need .ref class for primtive class ? In-Reply-To: <1025656701.6673192.1641495054893.JavaMail.zimbra@u-pem.fr> References: <1025656701.6673192.1641495054893.JavaMail.zimbra@u-pem.fr> Message-ID: <127499830.6678892.1641497077746.JavaMail.zimbra@u-pem.fr> ----- Original Message ----- > From: "Remi Forax" > To: "valhalla-spec-experts" > Sent: Thursday, January 6, 2022 7:50:54 PM > Subject: Why do we need .ref class for primtive class ? > It just occurs to me that while ACC_VALUE is a bit that change the runtime > semantics, > something the VM should take care of, ACC_PRIMITIVE is not a bit that change the > runtime semantics, only the javac translation strategy, > javac emits Q-types instead of L-type + the Preload attribute. > > If value classes and primitive classes are equivalent at runtime, why do we need > to generate the .ref interface/abstract class ? > We can use L-type instead. Just to be clear, it's not about removing Complex.ref from the language but to translate it to LComplex; R?mi From brian.goetz at oracle.com Thu Jan 6 20:12:21 2022 From: brian.goetz at oracle.com (Brian Goetz) Date: Thu, 6 Jan 2022 15:12:21 -0500 Subject: Why do we need .ref class for primtive class ? In-Reply-To: <1025656701.6673192.1641495054893.JavaMail.zimbra@u-pem.fr> References: <1025656701.6673192.1641495054893.JavaMail.zimbra@u-pem.fr> Message-ID: Because the Q is what permits the tearing. On 1/6/2022 1:50 PM, Remi Forax wrote: > It just occurs to me that while ACC_VALUE is a bit that change the runtime semantics, > something the VM should take care of, ACC_PRIMITIVE is not a bit that change the > runtime semantics, only the javac translation strategy, > javac emits Q-types instead of L-type + the Preload attribute. > > If value classes and primitive classes are equivalent at runtime, why do we need to generate the .ref interface/abstract class ? > We can use L-type instead. > > R?mi From forax at univ-mlv.fr Thu Jan 6 22:08:03 2022 From: forax at univ-mlv.fr (forax at univ-mlv.fr) Date: Thu, 6 Jan 2022 23:08:03 +0100 (CET) Subject: Why do we need .ref class for primtive class ? In-Reply-To: References: <1025656701.6673192.1641495054893.JavaMail.zimbra@u-pem.fr> Message-ID: <387808400.6729306.1641506883754.JavaMail.zimbra@u-pem.fr> Let me re-phrase my question because i've asked the wrong question. My question is not why do we need .ref in the language but why .ref can not be represented by a L-type in the bytecode instead of a full reified interface/abstract class. Asking for a .ref is something similar to a boxing, but using checkcast to convert from a QComplex; to a LComplex; One reason may be that this is not a subtyping relationship but a boxing relationship so it may not work when well we will have fully reified generics. R?mi > From: "Brian Goetz" > To: "Remi Forax" , "valhalla-spec-experts" > > Sent: Thursday, January 6, 2022 9:12:21 PM > Subject: Re: Why do we need .ref class for primtive class ? > Because the Q is what permits the tearing. > On 1/6/2022 1:50 PM, Remi Forax wrote: >> It just occurs to me that while ACC_VALUE is a bit that change the runtime >> semantics, >> something the VM should take care of, ACC_PRIMITIVE is not a bit that change the >> runtime semantics, only the javac translation strategy, >> javac emits Q-types instead of L-type + the Preload attribute. >> If value classes and primitive classes are equivalent at runtime, why do we need >> to generate the .ref interface/abstract class ? >> We can use L-type instead. >> R?mi From brian.goetz at oracle.com Thu Jan 6 22:18:30 2022 From: brian.goetz at oracle.com (Brian Goetz) Date: Thu, 6 Jan 2022 17:18:30 -0500 Subject: [External] : Re: Why do we need .ref class for primtive class ? In-Reply-To: <387808400.6729306.1641506883754.JavaMail.zimbra@u-pem.fr> References: <1025656701.6673192.1641495054893.JavaMail.zimbra@u-pem.fr> <387808400.6729306.1641506883754.JavaMail.zimbra@u-pem.fr> Message-ID: For a B3 class, .ref *is* indicated by an L type: ??? void m(Point p) { }????? // (QPoint;)V ??? void m(Point.ref p) { }? // (LPoint;)V On 1/6/2022 5:08 PM, forax at univ-mlv.fr wrote: > Let me re-phrase my question because i've asked the wrong question. > > My question is not why do we need .ref in the language but why .ref > can not be represented by a L-type in the bytecode instead of a full > reified interface/abstract class. > > Asking for a .ref is something similar to a boxing, but using > checkcast to convert from a QComplex; to a LComplex; > > One reason may be that this is not a subtyping relationship but a > boxing relationship so it may not work when well we will have fully > reified generics. > > R?mi > > ------------------------------------------------------------------------ > > *From: *"Brian Goetz" > *To: *"Remi Forax" , "valhalla-spec-experts" > > *Sent: *Thursday, January 6, 2022 9:12:21 PM > *Subject: *Re: Why do we need .ref class for primtive class ? > > Because the Q is what permits the tearing. > > On 1/6/2022 1:50 PM, Remi Forax wrote: > > It just occurs to me that while ACC_VALUE is a bit that change the runtime semantics, > something the VM should take care of, ACC_PRIMITIVE is not a bit that change the > runtime semantics, only the javac translation strategy, > javac emits Q-types instead of L-type + the Preload attribute. > > If value classes and primitive classes are equivalent at runtime, why do we need to generate the .ref interface/abstract class ? > We can use L-type instead. > > R?mi > > > From forax at univ-mlv.fr Wed Jan 12 11:45:18 2022 From: forax at univ-mlv.fr (Remi Forax) Date: Wed, 12 Jan 2022 12:45:18 +0100 (CET) Subject: L-type, Q-type and class mirrors Message-ID: <1303352024.10598834.1641987918801.JavaMail.zimbra@u-pem.fr> Hi all, i want to propose a way to reconcile builtin primitive types and primitive classes in the B1/B2/B3 world. Let's take a detour, and try to answer to the question, how do we do reflection on method with Q-types ? Given that reflection is using the class java.lang.Class, it means that we need a class that represents a L-type and a class that represent a Q-type. The class that represents a Q-type does not have to be a 'real' class, the same way int.class (Integer.TYPE) is not a real class, it's a mirror class that represent 'I' in the method signature, same with void.class (Void.TYPE) represent 'V'. So the class that represents a Q-type is a mirror class synthesized by the VM at runtime. Given that it is synthesized, i believe it should be only accessible using a method of java.lang.Class, by example Complex.class.mirrorType() // the name "mirror" is perhaps not the best Once we agree about that, we can push a little further and see how we can have only one unified kind of primitive class. If we want to be able to have an ArrayList of int, we need either to see int as a Q-type or Integer as a Q-type. The later is more attractive because it means that at runtime we can see a ArrayList as an ArrayList so call a method of an existing API using ArrayList with the more compact ArrayList. So java.lang.Integer is a primitive class. But it's not a true primitive class because - in a method descriptor because of backward compatibility, it has to be a Ljava/lang/Integer; - inside the '<' '>' of a generics, we need a way to express a Q-type. I propose to introduce a new kind of primitive class, the builtin primitive class, that - use L-type in signature - are eagerly loaded by the VM (this is already the case) thus does not need to appear in the attribute Preload. - this is more controversial, inside a generics, int is translated by the compiler to Qjava/lang/Integer; + usual boxing/unboxing operations so ArrayList is a specialized generics using the class miror corresponding to Qjava/lang/Integer; as argument. In practice, only the wrapper types, Byte, Short, Integer, etc, can be declared as builtin primitive (by example, the compiler can restrict the use of builtin to java.base or java.lang). R?mi From brian.goetz at oracle.com Wed Jan 12 12:27:07 2022 From: brian.goetz at oracle.com (Brian Goetz) Date: Wed, 12 Jan 2022 07:27:07 -0500 Subject: L-type, Q-type and class mirrors In-Reply-To: <1303352024.10598834.1641987918801.JavaMail.zimbra@u-pem.fr> References: <1303352024.10598834.1641987918801.JavaMail.zimbra@u-pem.fr> Message-ID: <3d3a4d14-14ed-ce41-1c77-11f642e6dcc4@oracle.com> > Let's take a detour, and try to answer to the question, how do we do reflection on method with Q-types ? > Given that reflection is using the class java.lang.Class, it means that we need a class that represents a L-type and a class that represent a Q-type. Correct.? In addition to all sorts of VM reasons for this, users need a way of distinguishing between ??? m(Point.ref p) and ??? m(Point p) with reflection, MH.Lookup, etc. > The class that represents a Q-type does not have to be a 'real' class, the same way int.class (Integer.TYPE) is not a real class, > it's a mirror class that represent 'I' in the method signature, same with void.class (Void.TYPE) represent 'V'. Correct.? We've been calling these "secondary mirrors".? Note that with extended primitives, it is possible (though not required) that the secondary mirror reflect almost everything that the primary does -- methods, fields, supertypes, etc.? Alternately, they could be more like int.class, which is pretty limited. Unfortunately, though, we run into a user expectation problem: users will reasonable expect that if they reflect over ??? m(Point p) they will get Point.class back.? Since the user views "Point" as the primary type (Point.ref is a supporting player), they'll expect Point.class to be the "important" mirror.? This asymmetry with the current state of affairs is a challenge. > So the class that represents a Q-type is a mirror class synthesized by the VM at runtime. > Given that it is synthesized, i believe it should be only accessible using a method of java.lang.Class, > by example > Complex.class.mirrorType() // the name "mirror" is perhaps not the best Stepping back, what you're saying is to expose only Point.class, and make it harder to get at the "other" mirror, such as by relegating it to a method like Class::otherMirror.? This is a reasonable move, but it does run smack into the above problem -- that if there's one mirror, users will expect Point.class to reflect the Point type they are most familiar with, which is QPoint. > I propose to introduce a new kind of primitive class, the builtin primitive class, that Whether we call it that, or summon it by magic, we are stuck with some form of this anyway, because of the asymmetries you've observed; the existing int/Integer pairs have subtle differences from declared Point/Point.ref pairs.? There will have to be some special pleading for built-in/legacy/basic primitives. I think where you're going is some flavor of this: ??? special-legacy-backwards value class Integer ??????? with-legacy-primitive int { ... } where we declare the Integer/int pair, but do so through Integer, but declare it to be backwards from the other primitives, where there are only eight of these allowed. From forax at univ-mlv.fr Wed Jan 12 12:31:17 2022 From: forax at univ-mlv.fr (Remi Forax) Date: Wed, 12 Jan 2022 13:31:17 +0100 (CET) Subject: VM model and aconst_init Message-ID: <2016676454.10625433.1641990677691.JavaMail.zimbra@u-pem.fr> I've some troubles to wrap my head around those two sentences """ aconst_init is the analogue of new for value objects; it leaves a reference to the initial value for a value class on the stack. This initial value is guaranteed to not be equal to null. The sole operand of this bytecode is a reference to a CONSTANT_Class item giving the internal binary name of the value class (not its Q descriptor). """ and """ Both withfield and aconst_init return a Q type if and only if their class is a primitive class. """ The second is ambiguous because it's not clear if aconst_init can return a L-type. I suppose it can not but this is not clear at all. If this is the case, what is the use case for withfield taking a L-type as parameter ?? regards, R?mi From brian.goetz at oracle.com Wed Jan 12 12:45:34 2022 From: brian.goetz at oracle.com (Brian Goetz) Date: Wed, 12 Jan 2022 07:45:34 -0500 Subject: VM model and aconst_init In-Reply-To: <2016676454.10625433.1641990677691.JavaMail.zimbra@u-pem.fr> References: <2016676454.10625433.1641990677691.JavaMail.zimbra@u-pem.fr> Message-ID: <271fec68-0102-4460-8ba4-fd1ff8c66994@oracle.com> Both value and primitive classes use the aconst_init / withfield initialization protocol.? The former is an L-type (QOptional is illegal); the latter uses Q types for initialization. Value classes ?-> are L types ?-> which are references ?-> references can be null ?-> VM manages where the nullity bits are so for value classes, there has to be some way of starting the ball rolling with an uninitialized, but non-null, value.? We can then modify the fields (but not the nullity) with `withfield`. On 1/12/2022 7:31 AM, Remi Forax wrote: > I've some troubles to wrap my head around those two sentences > > """ > aconst_init is the analogue of new for value objects; it leaves a reference to the initial value for a value class on the stack. This initial value is guaranteed to not be equal to null. The sole operand of this bytecode is a reference to a CONSTANT_Class item giving the internal binary name of the value class (not its Q descriptor). > """ > > and > """ > Both withfield and aconst_init return a Q type if and only if their class is a primitive class. > """ > > The second is ambiguous because it's not clear if aconst_init can return a L-type. I suppose it can not but this is not clear at all. > > If this is the case, what is the use case for withfield taking a L-type as parameter ?? > > regards, > R?mi From forax at univ-mlv.fr Wed Jan 12 13:10:35 2022 From: forax at univ-mlv.fr (forax at univ-mlv.fr) Date: Wed, 12 Jan 2022 14:10:35 +0100 (CET) Subject: L-type, Q-type and class mirrors In-Reply-To: <3d3a4d14-14ed-ce41-1c77-11f642e6dcc4@oracle.com> References: <1303352024.10598834.1641987918801.JavaMail.zimbra@u-pem.fr> <3d3a4d14-14ed-ce41-1c77-11f642e6dcc4@oracle.com> Message-ID: <1680706175.10653631.1641993035945.JavaMail.zimbra@u-pem.fr> ----- Original Message ----- > From: "Brian Goetz" > To: "Remi Forax" , "valhalla-spec-experts" > Sent: Wednesday, January 12, 2022 1:27:07 PM > Subject: Re: L-type, Q-type and class mirrors >> Let's take a detour, and try to answer to the question, how do we do reflection >> on method with Q-types ? >> Given that reflection is using the class java.lang.Class, it means that we need >> a class that represents a L-type and a class that represent a Q-type. > > Correct.? In addition to all sorts of VM reasons for this, users need a > way of distinguishing between > > ??? m(Point.ref p) > and > ??? m(Point p) > > with reflection, MH.Lookup, etc. > >> The class that represents a Q-type does not have to be a 'real' class, the same >> way int.class (Integer.TYPE) is not a real class, >> it's a mirror class that represent 'I' in the method signature, same with >> void.class (Void.TYPE) represent 'V'. > > Correct.? We've been calling these "secondary mirrors".? Note that with > extended primitives, it is possible (though not required) that the > secondary mirror reflect almost everything that the primary does -- > methods, fields, supertypes, etc.? Alternately, they could be more like > int.class, which is pretty limited. > > Unfortunately, though, we run into a user expectation problem: users > will reasonable expect that if they reflect over > > ??? m(Point p) > > they will get Point.class back.? Since the user views "Point" as the > primary type (Point.ref is a supporting player), they'll expect > Point.class to be the "important" mirror.? This asymmetry with the > current state of affairs is a challenge. There are two asymmetries, and we need to pick one. Either we allow Point.ref.class and in that case, you are right that EnclosingClass.class.getMethod("m").getParameterType(0) as to return a class that represent a QPoint;. Or we consider that Point.ref is a type, so Point.ref.class does not exist the same way List.class or List.class do not exist, in that case, Point.class.mirror() does not to have fields, methods, etc attached, the same way int.class has no fields/methods. In the latter case, it's also important that the secondary mirror has an invalid name, a name like "Point\mirror" or whatever that shows that it's a synthetic class so like Class.forName("int") does not work, Class.forName(Point.class.mirror()) should not work too. > >> So the class that represents a Q-type is a mirror class synthesized by the VM at >> runtime. >> Given that it is synthesized, i believe it should be only accessible using a >> method of java.lang.Class, >> by example >> Complex.class.mirrorType() // the name "mirror" is perhaps not the best > > Stepping back, what you're saying is to expose only Point.class, and > make it harder to get at the "other" mirror, such as by relegating it to > a method like Class::otherMirror.? This is a reasonable move, but it > does run smack into the above problem -- that if there's one mirror, > users will expect Point.class to reflect the Point type they are most > familiar with, which is QPoint. see above > >> I propose to introduce a new kind of primitive class, the builtin primitive >> class, that > > Whether we call it that, or summon it by magic, we are stuck with some > form of this anyway, because of the asymmetries you've observed; the > existing int/Integer pairs have subtle differences from declared > Point/Point.ref pairs.? There will have to be some special pleading for > built-in/legacy/basic primitives. > > I think where you're going is some flavor of this: > > ??? special-legacy-backwards value class Integer > ??????? with-legacy-primitive int { ... } > > where we declare the Integer/int pair, but do so through Integer, but > declare it to be backwards from the other primitives, where there are > only eight of these allowed. yes, but i think it should be a primitive class not a value class. R?mi From forax at univ-mlv.fr Wed Jan 12 13:14:12 2022 From: forax at univ-mlv.fr (forax at univ-mlv.fr) Date: Wed, 12 Jan 2022 14:14:12 +0100 (CET) Subject: VM model and aconst_init In-Reply-To: <271fec68-0102-4460-8ba4-fd1ff8c66994@oracle.com> References: <2016676454.10625433.1641990677691.JavaMail.zimbra@u-pem.fr> <271fec68-0102-4460-8ba4-fd1ff8c66994@oracle.com> Message-ID: <1555310797.10655508.1641993252455.JavaMail.zimbra@u-pem.fr> > From: "Brian Goetz" > To: "Remi Forax" , "valhalla-spec-experts" > > Sent: Wednesday, January 12, 2022 1:45:34 PM > Subject: Re: VM model and aconst_init > Both value and primitive classes use the aconst_init / withfield initialization > protocol. The former is an L-type (QOptional is illegal); the latter uses Q > types for initialization. > Value classes > -> are L types > -> which are references > -> references can be null > -> VM manages where the nullity bits are > so for value classes, there has to be some way of starting the ball rolling with > an uninitialized, but non-null, value. We can then modify the fields (but not > the nullity) with `withfield`. Ok, but in that case how the verifiers know if aconst_init generate a Q-type or a L-type given that aconst_init takes a CONSTANT_CLASS and not a descriptor as parameter. R?mi > On 1/12/2022 7:31 AM, Remi Forax wrote: >> I've some troubles to wrap my head around those two sentences >> """ >> aconst_init is the analogue of new for value objects; it leaves a reference to >> the initial value for a value class on the stack. This initial value is >> guaranteed to not be equal to null. The sole operand of this bytecode is a >> reference to a CONSTANT_Class item giving the internal binary name of the value >> class (not its Q descriptor). >> """ >> and >> """ >> Both withfield and aconst_init return a Q type if and only if their class is a >> primitive class. >> """ >> The second is ambiguous because it's not clear if aconst_init can return a >> L-type. I suppose it can not but this is not clear at all. >> If this is the case, what is the use case for withfield taking a L-type as >> parameter ?? >> regards, >> R?mi From brian.goetz at oracle.com Wed Jan 12 13:30:00 2022 From: brian.goetz at oracle.com (Brian Goetz) Date: Wed, 12 Jan 2022 08:30:00 -0500 Subject: [External] : Re: VM model and aconst_init In-Reply-To: <1555310797.10655508.1641993252455.JavaMail.zimbra@u-pem.fr> References: <2016676454.10625433.1641990677691.JavaMail.zimbra@u-pem.fr> <271fec68-0102-4460-8ba4-fd1ff8c66994@oracle.com> <1555310797.10655508.1641993252455.JavaMail.zimbra@u-pem.fr> Message-ID: <81fd637d-5538-2ea5-c674-8681ddf097a6@oracle.com> The operand of C_Class is a weird beast.? It can be an internal name (com/foo/Bar), but it can also be a *descriptor* for an array type.? Valhalla extends it to allow Q descriptors as well (but not L descriptors -- there should be one way to say C_Class[String].) On 1/12/2022 8:14 AM, forax at univ-mlv.fr wrote: > Ok, but in that case how the verifiers know if aconst_init generate a > Q-type or a L-type given that aconst_init takes a CONSTANT_CLASS and > not a descriptor as parameter. From daniel.smith at oracle.com Wed Jan 12 16:08:14 2022 From: daniel.smith at oracle.com (Dan Smith) Date: Wed, 12 Jan 2022 16:08:14 +0000 Subject: EG meeting, 2022-01-12 Message-ID: EG Zoom meeting today at 5pm UTC (9am PDT, 12pm EDT). We've had a flurry of activity in the last month. The list is below; probably best for those involved to decide whether they feel like the topic is settled, or deserves further discussion. "JEP update: Primitive Classes": revisions to JEP 401 to complement the new Value Objects JEP "Enhancing java.lang.constant for Valhalla": discussing whether/how the Preload attribute is manifested in this API "We have to talk about 'primitive'": terminology discussion regarding the word "primitive" "JEP update: Value Objects": followup discussion about inference/checking/usage of the IdentityObject & ValueObject interfaces "Updated State of Valhalla documents": revisions to the big-picture-oriented State of Valhalla documents to reflect recent design changes "Why do we need .ref class for primitive class?": clearing up how '.ref' types are encoded in bytecode "L-type, Q-type and class mirrors": discussing how '.ref' types are modeled by reflection "VM model and aconst_init": discussion how 'aconst_init' interacts with 'null' and verification types From kevinb at google.com Wed Jan 12 16:14:49 2022 From: kevinb at google.com (Kevin Bourrillion) Date: Wed, 12 Jan 2022 08:14:49 -0800 Subject: EG meeting, 2022-01-12 In-Reply-To: References: Message-ID: Can't attend today, but.... On Wed, Jan 12, 2022 at 8:08 AM Dan Smith wrote: "We have to talk about 'primitive'": terminology discussion regarding the > word "primitive" > I'm planning to continue this conversation on-thread, so no worries for now. -- Kevin Bourrillion | Java Librarian | Google, Inc. | kevinb at google.com From forax at univ-mlv.fr Wed Jan 12 16:45:04 2022 From: forax at univ-mlv.fr (forax at univ-mlv.fr) Date: Wed, 12 Jan 2022 17:45:04 +0100 (CET) Subject: [External] : Re: VM model and aconst_init In-Reply-To: <81fd637d-5538-2ea5-c674-8681ddf097a6@oracle.com> References: <2016676454.10625433.1641990677691.JavaMail.zimbra@u-pem.fr> <271fec68-0102-4460-8ba4-fd1ff8c66994@oracle.com> <1555310797.10655508.1641993252455.JavaMail.zimbra@u-pem.fr> <81fd637d-5538-2ea5-c674-8681ddf097a6@oracle.com> Message-ID: <1823500600.10802162.1642005904641.JavaMail.zimbra@u-pem.fr> > From: "Brian Goetz" > To: "Remi Forax" > Cc: "valhalla-spec-experts" > Sent: Wednesday, January 12, 2022 2:30:00 PM > Subject: Re: [External] : Re: VM model and aconst_init > The operand of C_Class is a weird beast. It can be an internal name > (com/foo/Bar), but it can also be a *descriptor* for an array type. Valhalla > extends it to allow Q descriptors as well (but not L descriptors -- there > should be one way to say C_Class[String].) Your explanation maks sense but it's not was this sentence says """ The sole operand of this bytecode is a reference to a CONSTANT_Class item giving the internal binary name of the value class (not its Q descriptor) """ R?mi > On 1/12/2022 8:14 AM, [ mailto:forax at univ-mlv.fr | forax at univ-mlv.fr ] wrote: >> Ok, but in that case how the verifiers know if aconst_init generate a Q-type or >> a L-type given that aconst_init takes a CONSTANT_CLASS and not a descriptor as >> parameter. From daniel.smith at oracle.com Wed Jan 12 23:26:32 2022 From: daniel.smith at oracle.com (Dan Smith) Date: Wed, 12 Jan 2022 23:26:32 +0000 Subject: Terminology bikeshedding summary Message-ID: <1F2A06FF-582A-44A6-BD01-BA52673DB716@oracle.com> EG meeting touched on a few different renaming ideas to consider. Wanted to put those all down in one place. Personally, I don't have strong feelings about any of these. I think the status quo is reasonable, and these changes would probably be fine, too (modulo coming up with the right word in some cases). Some of this faces an inherent conflict between different views/models/users, and we won't be able to please everybody; the choice is about which of those views/models/users we want to emphasize. #1: value class vs. [something else] class I don't recall a concrete proposal, but this reflects some discomfort with the idea that "value" is being used differently than when we talk about "the value of a variable" or, from some other languages, a "value type". #2: primitive class vs. bare value class vs. [something else] value class primitive type vs. bare value type vs. [something else] value type primitive value vs. bare value vs. [something else] value Three objections to "primitive": - Asking developers to loosen their notion of "primitive" to include user-defined, composite types may be too much of a conceptual shift/abuse of terminology - The original 8 primitives still have a number of properties that make them special, perhaps deserving a convenient, one-word name (on the other hand, *not* giving them a distinct name helpfully communicates that these differences should not be considered significant...) - It's useful to highlight that these things are still a kind of value class, in some sense reducing the conceptual overhead (there are identity classes and value classes, everything else is secondary) #3: primitive value vs. object We're trying to make a distinction between primitive values being "class instances" and calling them "objects", but for many developers, especially beginners, that sounds like meaningless pedantry. We might be over-rotating on the subtle differences that make these entities distinct, rather than acknowledging that, with their fields and methods, they will be commonly understood to be a kind of object. From john.r.rose at oracle.com Thu Jan 13 00:05:19 2022 From: john.r.rose at oracle.com (John Rose) Date: Thu, 13 Jan 2022 00:05:19 +0000 Subject: Terminology bikeshedding summary In-Reply-To: <1F2A06FF-582A-44A6-BD01-BA52673DB716@oracle.com> References: <1F2A06FF-582A-44A6-BD01-BA52673DB716@oracle.com> Message-ID: #3 is more like: primitive value vs. bare object Or primitive value vs. [something else] object Where object is split not only into value object and identity objects, but bare (value) objects are another split. You get bare vs heap just as you get value vs identity as cleavage planes in the universe of objects. Also: Legacy primitives would not be objects in any case. But we can mock up classes to wrap and/or emulate them and even declare in the user model that these very special classes in some sense ?are? the primitives. > On Jan 12, 2022, at 3:27 PM, Dan Smith wrote: > > #3: > > primitive value vs. object From daniel.smith at oracle.com Thu Jan 13 00:21:55 2022 From: daniel.smith at oracle.com (Dan Smith) Date: Thu, 13 Jan 2022 00:21:55 +0000 Subject: JEP update: Classes for the Basic Primitives Message-ID: I'm made some revisions to JEP 402 to better track with the revised JEP 401?in particular backing off of "everything is an object". There were some short-lived changes where I more aggressively pursued the idea that the class was named 'int', but I've backed off of that, too. Now taking the more conservative approach that there is a primitive class named 'Integer', but by special rule its primitive type is expressed 'int', and the class name refers to the reference type. I realize that much of this could potentially change?reflection story, terminology, etc. But consider this the "plan of record" for now. https://bugs.openjdk.java.net/browse/JDK-8259731 From john.r.rose at oracle.com Wed Jan 19 08:40:15 2022 From: john.r.rose at oracle.com (John Rose) Date: Wed, 19 Jan 2022 00:40:15 -0800 Subject: VM model and aconst_init In-Reply-To: <2016676454.10625433.1641990677691.JavaMail.zimbra@u-pem.fr> References: <2016676454.10625433.1641990677691.JavaMail.zimbra@u-pem.fr> Message-ID: <1BB6397E-2103-4AF3-A857-02CF2FA0B453@oracle.com> I think (based on our most recent conversations) that `aconst_init` can return a Q-type for B3 types and an L-type for B2 types. And likewise for the input and output of `withfield`. The net result is that both bytecodes need to be permissive about L and Q types, because B2 and B3 translation strategies require distinct parallel use cases. This is probably not clear in the docs, but I think it makes sense. Can you mix and match both modes in the same method? Probably, since the interpreter doesn?t care about multi-bytecode patterns. Dunno if this causes a testing problem, and if so how to fix it. I think it?s probably OK, especially if we require the two-way checkcast (Q-Foo not a subtype of L-Foo in the verifier) so that each mode stays ?in its own lane?. More explicitly, this is a set of use cases for using Q-types in C_Class entries in the constant pool to switch to Q-mode for bytecodes that refer to classes, including `withfield` and `aconst_init`. On 12 Jan 2022, at 4:31, Remi Forax wrote: > I've some troubles to wrap my head around those two sentences > > """ > aconst_init is the analogue of new for value objects; it leaves a > reference to the initial value for a value class on the stack. This > initial value is guaranteed to not be equal to null. The sole operand > of this bytecode is a reference to a CONSTANT_Class item giving the > internal binary name of the value class (not its Q descriptor). > """ > > and > """ > Both withfield and aconst_init return a Q type if and only if their > class is a primitive class. > """ > > The second is ambiguous because it's not clear if aconst_init can > return a L-type. I suppose it can not but this is not clear at all. > > If this is the case, what is the use case for withfield taking a > L-type as parameter ?? > > regards, > R?mi From john.r.rose at oracle.com Wed Jan 19 08:46:21 2022 From: john.r.rose at oracle.com (John Rose) Date: Wed, 19 Jan 2022 00:46:21 -0800 Subject: VM model and aconst_init In-Reply-To: <1555310797.10655508.1641993252455.JavaMail.zimbra@u-pem.fr> References: <2016676454.10625433.1641990677691.JavaMail.zimbra@u-pem.fr> <271fec68-0102-4460-8ba4-fd1ff8c66994@oracle.com> <1555310797.10655508.1641993252455.JavaMail.zimbra@u-pem.fr> Message-ID: <40C9D97F-49E9-4A5A-97E3-BDCFDB8CE3D7@oracle.com> On 12 Jan 2022, at 5:14, forax at univ-mlv.fr wrote: > Ok, but in that case how the verifiers know if aconst_init generate a > Q-type or a L-type given that aconst_init takes a CONSTANT_CLASS and > not a descriptor as parameter. In the terms of my previous message, the `CONSTANT_Class` item in the CP must be ?modal?, refer to either an L-type or Q-type. That?s true whether it is the direct operand of `aconst_init` or a sub-operand of `withfield`. All of this (about pervasive use of bimodal `C_Class` items) is hard to avoid. I would have preferred to say that `C_Class` items are always for L-types, but that runs afoul of other requirements, notably that Point.class be the mirror for Q-Point not L-Point if Point is a B3-capable class. From john.r.rose at oracle.com Wed Jan 19 08:47:26 2022 From: john.r.rose at oracle.com (John Rose) Date: Wed, 19 Jan 2022 00:47:26 -0800 Subject: [External] : Re: VM model and aconst_init In-Reply-To: <1823500600.10802162.1642005904641.JavaMail.zimbra@u-pem.fr> References: <2016676454.10625433.1641990677691.JavaMail.zimbra@u-pem.fr> <271fec68-0102-4460-8ba4-fd1ff8c66994@oracle.com> <1555310797.10655508.1641993252455.JavaMail.zimbra@u-pem.fr> <81fd637d-5538-2ea5-c674-8681ddf097a6@oracle.com> <1823500600.10802162.1642005904641.JavaMail.zimbra@u-pem.fr> Message-ID: <01754CF4-6757-4BDD-99B3-E82A5FCD4C62@oracle.com> On 12 Jan 2022, at 8:45, forax at univ-mlv.fr wrote: >> From: "Brian Goetz" >> To: "Remi Forax" >> Cc: "valhalla-spec-experts" >> Sent: Wednesday, January 12, 2022 2:30:00 PM >> Subject: Re: [External] : Re: VM model and aconst_init > >> The operand of C_Class is a weird beast. It can be an internal name >> (com/foo/Bar), but it can also be a *descriptor* for an array type. Valhalla >> extends it to allow Q descriptors as well (but not L descriptors -- >> there >> should be one way to say C_Class[String].) > Your explanation maks sense but it's not was this sentence says > """ > The sole operand of this bytecode is a reference to a CONSTANT_Class item giving the internal binary name of the value class (not its Q descriptor) > """ > That was? aspirational. From brian.goetz at oracle.com Wed Jan 19 23:57:25 2022 From: brian.goetz at oracle.com (Brian Goetz) Date: Wed, 19 Jan 2022 18:57:25 -0500 Subject: SoV-2: weak references In-Reply-To: References: Message-ID: It certainly seems that all the choices are bad. The "obvious" choice is to simply say that WeakReference makes no sense, in that it sidesteps the hard semantics questions.? My fear is that this will cause new failures, where existing libraries that toss objects into WHMs to cache derived results, will start to experience new failures when the value types show up in the heap (after all, WeakReference::new takes Object.)? And we'll have to have something to tell those users, because they declared a WeakHashMap, and someone created a value subtype of User -- which seems entirely valid. It is possible we could do something special with WHM, since it is layered atop WR, but that still begs the question -- what? On 1/19/2022 4:28 PM, Dan Heidinga wrote: > In the Dec 2021 update to State of Valhalla, part 2: The language > model, the section on "Identity-sensitive operations" states this > about weak references: > >> Weak references to value objects that contain no references to identity objects should never be >> cleared; weak references to value objects that contain references to identity objects should be >> cleared when those objects are no longer strongly reachable. > I'm concerned that this approach makes using weak references correctly > for values very difficult, especially in the face of scalarization. > > Scalarization allows separating values into their individual > components and flowing them separately through the code. This can - > with some caveats for decompilation and maybe other features - result > in very different lifetimes for each separate component, with some > object references going out of scope "earlier" than expected. The > source code will of course show the *entire* value being carried along > even though only a single component may survive post-scalarization > which means developers will see very different behaviour between the > interpreter (which doesn't scalarize) and jitted code - making it very > easy to write tests that give them the wrong impression. > > Reference::reachabilityFence was added in Java 9 to help users deal > with premature finalization and has gotten little attention from most > users. The proposed semantics for WeakReferences on value objects will > drag the reachabilityFence method into the light and expose users to a > problem they'd rather not have. Just as we avoided exposing most > users to tearing of their (bucket 2) value objects, we shouldn't > expose them to having to reason about complicated reachability rules. > > Which is to say, Reference objects and value objects need to be > incompatible to give users what they expect. Anything else is loading > a gun and pointing it at their feet. > > Here's an example of why the suggested rules for weak references using > the identity objects may bring reachability issues to the forefront > (where we don't want them): > > public value class ResourcePair { > static long nativePtr; > static IdentityObject companion; > > ResourcePair(long ptr, IdentityObject o) { > nativePtr = ptr; > companion = o; > } > } > > class PtrRef extends WeakReference { > long nativePtr; > > PtrRef(ResourcePair p, ReferenceQueue q) { > super(p, q); > nativePtr = p.nativePtr; > } > > void free() { /* do something to nativePtr */ } > } > > If the `companion` object of the ResourcePair value goes out of scope > before `nativePtr` is done being used - the issue of reachabilityFence > - the ReferenceQueue processor could call free() before the > `nativePtr` is done being used. Scalarization will make this more > common and even very common if we're getting the benefits we expect > from it. > > --Dan > From wrprice at gmail.com Thu Jan 20 22:47:05 2022 From: wrprice at gmail.com (William Price) Date: Thu, 20 Jan 2022 16:47:05 -0600 Subject: Terminology bikeshedding summary Message-ID: Hello all, I've been observing the Valhalla-spec-experts list via the archives for quite a while and enjoying the progress. I am eagerly awaiting the new JEPs and meanwhile thinking to myself how I would mentor other developers on how and when to (not) use these features once released into the language. With the recent thread on bikeshedding your B1/B2/B3 categories, some thoughts popped into my head and I'd like to be so bold as to share them from the perspective of a (power) user and someone acting in a mentor role. > #1. value class vs. [something else] class Value types will have no object identity, and that's important to understand from the perspective of monitors and how the JVM treats such types in memory, but I don't think most developers synchronize on their objects. The effects on `==` vs `equals(Object)` behaviors are probably the most important for "lay" and beginning Java devs to get right. So in my head I read the above as, "value equivalence class" vs "intrinsic identity class", with a focus on the behavior of the `==` operator. Of course, that's too verbose as far as syntax goes. I think "value class" is clear and concise for source code. > #2. > primitive class vs. bare value class vs. [something else] value class > primitive type vs. bare value type vs. [something else] value type > primitive value vs. bare value vs. [something else] value I'll add my voice behind those saying leave "primitive" alone as much as possible. The definition of the word matches w/ the specialized behavior supported by the underlying VM. The set of primitive types remains the base case of all data structures enabled by the type system. Long-time users, at least those who are less receptive to change, are going to have enough on their plate w/ the introduction of "value class". The use of the word "bare" isn't sitting well with me, either; probably because it will require a verbose definition to have any meaning to most users. I don't think developers are going to think of their values as "clothed" or not. ;-) The closest use of "bare" in computation that I can think of is "bare metal" referring to hardware and the lack of virtualization (or abstraction!). I can see an argument that flattened layouts are closer to the "bare" metal, but that's a VM/hardware centric view. To your average developer, Valhalla is introducing quite a bit more complexity to the VM abstraction between the source code and the metal. (That's assuming the developer cares to understand how the VM works its magic in the first place.) >From the above two paragraphs, I'm squarely in camp "[something else]" and I'll get to that something in a moment. > #3: > primitive value vs. object > > We're trying to make a distinction between primitive values being "class instances" and > calling them "objects", but for many developers, especially beginners, that sounds like > meaningless pedantry. +1. Let "objects are instances of a class" remain true and apply to all of these new types. One only has to look through the Java Tutorials section on Creating Objects[1] to see that the developer's syntax when working with proposed value- and [something else] classes will largely mirror the existing experience with classic objects -- all the way from `new`, constructor-call syntax, and `instanceof`. What Valhalla is proposing to change is that [something else], which had previously been limited to primitives, are now objects (instances) too, but not all objects have identity. If that interpretation is correct, then "everything is an object" isn't too hard to explain. > #3 is more like: > > primitive value vs. bare object > Or > primitive value vs. [something else] object > > Where object is split not only into value object and identity objects, but bare (value) objects > are another split. You get bare vs heap just as you get value vs identity as cleavage planes > in the universe of objects. > > Also: > > Legacy primitives would not be objects in any case. But we can mock up classes to wrap > and/or emulate them and even declare in the user model that these very special classes in > some sense ?are? the primitives. This is what caused a *click* in my head and prompted this e-mail. It reminded me of how, after Java 5 introduced `enum` types, I don't recall myself or any colleagues ever referring to "enum classes" outside of those dealing directly with reflection or bytecode manipulation. They're simply "enums". Despite the initial shock that one is defined in source as a `[] enum` absent the `class` or `interface` keyword, we all now understand that there's a class behind it, just as we previously understood that there was a `java.lang.Class` behind a proper `interface` type. Similarly, the primitive-value/bare/[something else] type WILL be understood to be both an object, and a value-type, and have a class representation at runtime/reflection. In the documentation, of course, it will need to be heavily emphasized that [something else] is not just flattenable but is also a value type. However, I don't feel that these attributes require heavy emphasis in the formal name. I favor "public [something]" over "public [something [value]] class", just as Java 5 did for enum. I've been working professionally in Java land for a long time, but when I look at the attributes of primitive/bare/[something else], as in JEP 401, what I see is a struct. Not the struct from Java's roots in C/C++ but the struct[2] from C#, which could be considered a closer comparison these days. Though the Valhalla proposal is not 1:1 with C#, the latter's (readonly) structs have methods, support inlining outside of heap, and many similar characteristics. This similarity may bring with it familiarity to developers coming from .NET ecosystems as a tangential benefit. For developers unfamiliar with C#, "struct" is still existing terminology that -- without any further definition -- should evoke thoughts of data structures and/or in-memory representation. Given this is a thread on bikeshedding, my humble opinion for syntax related to these new Valhalla classes/types is as follows: class Foo // identity-based L-type value class Bar // value-based L-type struct Qat // flattened value Q-type In recognition that structs in other languages do not implicitly impose `final` on their fields, and in the hope that perhaps direct inlined mutation might be allowed by future Java versions, I would also suggest that javac require an *explicit* `final` modifier on fields declared within a `struct` rather than rely on the implicit behavior of general value classes. Yes, it's more verbose, but that's countered by advice to users that they should use `struct` judiciously (due to tearing, etc.) and not go overboard with use -- in other words, the impact felt from that extra boilerplate should be rare. Of course, if you're certain you'll never-ever allow such fields to be non-final, then my above argument is moot. But I have had real-life cases where I think I would benefit from encapsulating and inlining struct-like classes within another class, avoiding the indirection, but supporting in-place mutation of individual struct fields. Implicitly final fields do not allow you to change your mind on this point without breaking source backwards compatibility in a way that might not be noticed upon a subsequent recompile. I'll stick my neck out farther and bring in this snippet from a different thread on the list. Brian, you wrote in response[3] to Remi: > I think where you're going is some flavor of this: > > special-legacy-backwards value class Integer > with-legacy-primitive int { ... } I may have missed the need for [special-legacy-backwards] separate from [with-legacy-primitive]. Given that [with-legacy-primitive] would be reserved for the JDK alone and not user-defined classes, I thought of several existing keywords that could be used in that place without *too* much head-scratching. But one in particular stood out for its potential simplicity: public struct Integer extends Number implements int, Comparable { private final int value; ^^^^ /* ... */ } - `int` and the other Language Keywords for primitives are not interfaces, so this is the special JDK-reserved behavior and the only "smell" that jumps out to me - `implements int`, read as English, says exactly what you mean for readers to understand - no new keywords or reserved identifiers required - The "backwards" behavior (Integer.class == int.ref?) is only applied to these special cases - Does not use the defined type (Integer) as a member field (non-circular) That's more than enough for now. Thank you for reading this far, and I'm eagerly anticipating the fruits of both Valhalla and Loom. [1]: https://docs.oracle.com/javase/tutorial/java/javaOO/objectcreation.html [2]: https://docs.microsoft.com/en-us/dotnet/csharp/language-reference/builtin-types/struct [3]: https://mail.openjdk.java.net/pipermail/valhalla-spec-experts/2022-January/001764.html -- William Price From forax at univ-mlv.fr Tue Jan 25 10:50:10 2022 From: forax at univ-mlv.fr (forax at univ-mlv.fr) Date: Tue, 25 Jan 2022 11:50:10 +0100 (CET) Subject: VM model and aconst_init In-Reply-To: <1BB6397E-2103-4AF3-A857-02CF2FA0B453@oracle.com> References: <2016676454.10625433.1641990677691.JavaMail.zimbra@u-pem.fr> <1BB6397E-2103-4AF3-A857-02CF2FA0B453@oracle.com> Message-ID: <1577708639.3794959.1643107810290.JavaMail.zimbra@u-pem.fr> > From: "John Rose" > To: "Remi Forax" > Cc: "valhalla-spec-experts" > Sent: Wednesday, January 19, 2022 9:40:15 AM > Subject: Re: VM model and aconst_init > I think (based on our most recent conversations) > that aconst_init can return a Q-type for B3 types > and an L-type for B2 types. And likewise for the input > and output of withfield . Yes ! > The net result is that both bytecodes need to be > permissive about L and Q types, because B2 and B3 > translation strategies require distinct parallel use > cases. > This is probably not clear in the docs, but I think > it makes sense. > Can you mix and match both modes in the same method? > Probably, since the interpreter doesn?t care about > multi-bytecode patterns. Dunno if this causes a testing > problem, and if so how to fix it. I think it?s probably > OK, especially if we require the two-way checkcast > (Q-Foo not a subtype of L-Foo in the verifier) so that > each mode stays ?in its own lane?. > More explicitly, this is a set of use cases for using > Q-types in C_Class entries in the constant pool to switch > to Q-mode for bytecodes that refer to classes, including > withfield and aconst_init . Let's talk a bit about having the L world and the Q world completely disjoint at least from the bytecode verifier POV. It means that we need some checkcasts to move in both direction, from a Q-type to a L-type and vice-versa. But at the same time, an array of L-type is a subtype of an array of Q-type ? The result to a very uncommon/unconventional type system, and i'm not a big fan of surprises in that area. Furthermore, i believe that subtyping is a key to avoid multiple bytecode verification of the generics code. By example, with the TypeRestriction attribute [1], the restriction has to be subtype of the declared type/descriptor. R?mi [1] https://cr.openjdk.java.net/~jrose/values/parametric-vm.html#type-restricted-methods-and-fields-and-the-typerestriction-attribute From brian.goetz at oracle.com Tue Jan 25 14:57:17 2022 From: brian.goetz at oracle.com (Brian Goetz) Date: Tue, 25 Jan 2022 14:57:17 +0000 Subject: VM model and aconst_init In-Reply-To: References: <2016676454.10625433.1641990677691.JavaMail.zimbra@u-pem.fr> <1BB6397E-2103-4AF3-A857-02CF2FA0B453@oracle.com> <1577708639.3794959.1643107810290.JavaMail.zimbra@u-pem.fr> Message-ID: <3CFB7ED1-2114-40A1-9EE1-81DC5D3647FF@oracle.com> The motivation for this comes from erasure. Even if we specialize, we need to be able to use specialized generics in an erased context, because there will be erased clients. If we have class Foo { T m(); T[] arr(); } we can use also sorts of bridging/casting tricks to make Foo work with the erasure of T to Object, but we?ve got much less latitude when we want to treat an int[] as an Object[]. Since arrays are mutable / identity objects, we can?t copy them even if we wanted to; we need an identity-preserving way to say ?this int[] array, as if it were an Object[]?. Rejigging array covariance to work over the ?extends? relation rather than the ?subtype? relation seems the least damaging way to get there. On Jan 25, 2022, at 9:40 AM, Dan Heidinga > wrote: Can you mix and match both modes in the same method? Probably, since the interpreter doesn?t care about multi-bytecode patterns. Dunno if this causes a testing problem, and if so how to fix it. I think it?s probably OK, especially if we require the two-way checkcast (Q-Foo not a subtype of L-Foo in the verifier) so that each mode stays ?in its own lane?. More explicitly, this is a set of use cases for using Q-types in C_Class entries in the constant pool to switch to Q-mode for bytecodes that refer to classes, including withfield and aconst_init. Let's talk a bit about having the L world and the Q world completely disjoint at least from the bytecode verifier POV. It means that we need some checkcasts to move in both direction, from a Q-type to a L-type and vice-versa. But at the same time, an array of L-type is a subtype of an array of Q-type ? The result to a very uncommon/unconventional type system, and i'm not a big fan of surprises in that area. I've been puzzling over this as well and echo your discomfort with it, mostly on the array side. I haven't been able to identify what the sharp edge here is though other than that it feels surprising. After playing with bytecode sequences, the part I'm not clear on is whether I can store an LFoo; into a [QFoo; directly, or do I need a checkcast QFoo; before the aastore? If I need the checkcast (and I think I do), then I'm starting to come around to the view that the array side isn't actually any different from what we'd do for any other subclass relationship. The checkcast for Q->L is still odd, but less concerning as it deals with new value semantics rather than changing the array covariance? For reference, the bytecodes sequences I've been looking at are the following: Convert with checkcast: -------------------------------- aload_1 checkcast QFoo; // or LFoo; and Convert with Q->L array store/load: --------------------------------------- anewarray //LFoo astore_2 aload_2 iconst_0 invokestatic QFoo.QFoo; // or any other way to get a Q aastore aload_2 iconst_0 aaload // use as an LFoo Convert with L->Q array store/load: --------------------------------------- anewarray //QFoo astore_2 aload_2 iconst_0 invokestatic X.getFoo:()LFoo; // Is a checkcast needed here first to downcast? I think so aastore aload_2 iconst_0 aaload // use as an QFoo --Dan Furthermore, i believe that subtyping is a key to avoid multiple bytecode verification of the generics code. By example, with the TypeRestriction attribute [1], the restriction has to be subtype of the declared type/descriptor. R?mi [1] https://cr.openjdk.java.net/~jrose/values/parametric-vm.html#type-restricted-methods-and-fields-and-the-typerestriction-attribute From forax at univ-mlv.fr Tue Jan 25 15:36:16 2022 From: forax at univ-mlv.fr (forax at univ-mlv.fr) Date: Tue, 25 Jan 2022 16:36:16 +0100 (CET) Subject: VM model and aconst_init In-Reply-To: <3CFB7ED1-2114-40A1-9EE1-81DC5D3647FF@oracle.com> References: <2016676454.10625433.1641990677691.JavaMail.zimbra@u-pem.fr> <1BB6397E-2103-4AF3-A857-02CF2FA0B453@oracle.com> <1577708639.3794959.1643107810290.JavaMail.zimbra@u-pem.fr> <3CFB7ED1-2114-40A1-9EE1-81DC5D3647FF@oracle.com> Message-ID: <1534054066.4049476.1643124976954.JavaMail.zimbra@u-pem.fr> > From: "Brian Goetz" > To: "Dan Heidinga" > Cc: "Remi Forax" , "John Rose" , > "valhalla-spec-experts" > Sent: Tuesday, January 25, 2022 3:57:17 PM > Subject: Re: VM model and aconst_init > The motivation for this comes from erasure. Even if we specialize, we need to be > able to use specialized generics in an erased context, because there will be > erased clients. If we have > class Foo { > T m(); > T[] arr(); > } > we can use also sorts of bridging/casting tricks to make Foo work with the > erasure of T to Object, but we?ve got much less latitude when we want to treat > an int[] as an Object[]. Since arrays are mutable / identity objects, we can?t > copy them even if we wanted to; we need an identity-preserving way to say ?this > int[] array, as if it were an Object[]?. Rejigging array covariance to work > over the ?extends? relation rather than the ?subtype? relation seems the least > damaging way to get there. Agree for T[], but don't we have the same issue with T.ref, a L-type can be specialized by a Q-type ? class Foo { T.ref field; } class Bar extends Foo { void m() { field = Qcomplex;.new(); } } R?mi >> On Jan 25, 2022, at 9:40 AM, Dan Heidinga < [ mailto:heidinga at redhat.com | >> heidinga at redhat.com ] > wrote: >>> Can you mix and match both modes in the same method? >>> Probably, since the interpreter doesn?t care about >>> multi-bytecode patterns. Dunno if this causes a testing >>> problem, and if so how to fix it. I think it?s probably >>> OK, especially if we require the two-way checkcast >>> (Q-Foo not a subtype of L-Foo in the verifier) so that >>> each mode stays ?in its own lane?. >>> More explicitly, this is a set of use cases for using >>> Q-types in C_Class entries in the constant pool to switch >>> to Q-mode for bytecodes that refer to classes, including >>> withfield and aconst_init. >>> Let's talk a bit about having the L world and the Q world completely disjoint at >>> least from the bytecode verifier POV. >>> It means that we need some checkcasts to move in both direction, from a Q-type >>> to a L-type and vice-versa. >>> But at the same time, an array of L-type is a subtype of an array of Q-type ? >>> The result to a very uncommon/unconventional type system, and i'm not a big fan >>> of surprises in that area. >> I've been puzzling over this as well and echo your discomfort with it, >> mostly on the array side. I haven't been able to identify what the >> sharp edge here is though other than that it feels surprising. >> After playing with bytecode sequences, the part I'm not clear on is >> whether I can store an LFoo; into a [QFoo; directly, or do I need a >> checkcast QFoo; before the aastore? If I need the checkcast (and I >> think I do), then I'm starting to come around to the view that the >> array side isn't actually any different from what we'd do for any >> other subclass relationship. The checkcast for Q->L is still odd, but >> less concerning as it deals with new value semantics rather than >> changing the array covariance? >> For reference, the bytecodes sequences I've been looking at are the following: >> Convert with checkcast: >> -------------------------------- >> aload_1 >> checkcast QFoo; // or LFoo; >> and >> Convert with Q->L array store/load: >> --------------------------------------- >> anewarray //LFoo >> astore_2 >> aload_2 >> iconst_0 >> invokestatic QFoo.QFoo; // or any other way to get a Q >> aastore >> aload_2 >> iconst_0 >> aaload // use as an LFoo >> Convert with L->Q array store/load: >> --------------------------------------- >> anewarray //QFoo >> astore_2 >> aload_2 >> iconst_0 >> invokestatic X.getFoo:()LFoo; >> // Is a checkcast needed here first to downcast? I think so >> aastore >> aload_2 >> iconst_0 >> aaload // use as an QFoo >> --Dan >>> Furthermore, i believe that subtyping is a key to avoid multiple bytecode >>> verification of the generics code. >>> By example, with the TypeRestriction attribute [1], the restriction has to be >>> subtype of the declared type/descriptor. >>> R?mi >>> [1] [ >>> https://cr.openjdk.java.net/~jrose/values/parametric-vm.html#type-restricted-methods-and-fields-and-the-typerestriction-attribute >>> | >>> https://cr.openjdk.java.net/~jrose/values/parametric-vm.html#type-restricted-methods-and-fields-and-the-typerestriction-attribute >>> ] From forax at univ-mlv.fr Tue Jan 25 21:39:25 2022 From: forax at univ-mlv.fr (Remi Forax) Date: Tue, 25 Jan 2022 22:39:25 +0100 (CET) Subject: The interfaces IdentityObject and ValueObject must die ! Message-ID: <1984046756.4249884.1643146765320.JavaMail.zimbra@u-pem.fr> I think we should revisit the idea of having the interfaces IdentityObject/ValueObject. They serve two purposes 1/ documentation: explain the difference between an identity class and a value class 2/ type restriction: can be used as type or bound of type parameter for algorithms that only works with identity class Sadly, our design as evolved but not those interfaces, they do not work well as type restriction, because the type is lost once an interface/j.l.Object is used and the cost of their introduction is higher than previously though. 1/ documentation - Those interface split the possible types in two groups but the spec split the types in 3, B1/B2/B3, thus they are not aligned anymore with the new design. - they will be noise in the future, for Valhalla, the separation between identity object and value object may be important but from a POV of someone learning/discovering the language it's a corner case (like primitives are). This is even more true with the introduction of B2, you can use B2 for a long time without knowing what a value type is. So having such interfaces front and center is too much. 2/ as type - Being a value class or a primitive class is a runtime behavior not a compile time behavior, so representing them with special types (a type is a compile time construct) will always be an approximation. As a consequence, you can have an identity class (resp value class) typed with a type which is not a subtype of IdentityObject (resp ValueObject). This discrepancy is hard to grasp for beginners (in fact not only for beginners) and make IdentityObject/ValueObject useless because if a method takes an IdentityObject as parameter but the type is an interface, users will have to cast it into an IdentityObject which defeat the purpose of having such interface. (This is the reason why ObjectOutputStream.writeObject() takes an Object as parameter and not Serializable) And the cost of introduction is high - they are not source backward compatible class A {} class B {} var list = List.of(new A(), new B()); List