From daniel.smith at oracle.com Wed May 1 04:18:33 2024 From: daniel.smith at oracle.com (Dan Smith) Date: Wed, 1 May 2024 04:18:33 +0000 Subject: EG meeting *canceled*, 2024-05-01 Message-ID: <894E6DFE-3C21-4FA9-B9A0-F4A88086F05D@oracle.com> Again, nothing new to discuss this time. On May 14, we'll be having some Oracle-internal Valhalla meetings and so we'll cancel that one too. I think that will lead to some useful updates for the May 28 meeting. From daniel.smith at oracle.com Wed May 1 04:19:19 2024 From: daniel.smith at oracle.com (Dan Smith) Date: Wed, 1 May 2024 04:19:19 +0000 Subject: EG meeting *canceled*, 2024-05-01 In-Reply-To: <894E6DFE-3C21-4FA9-B9A0-F4A88086F05D@oracle.com> References: <894E6DFE-3C21-4FA9-B9A0-F4A88086F05D@oracle.com> Message-ID: <28173CA5-E858-42E6-8937-29BEE6330436@oracle.com> > On Apr 30, 2024, at 9:18?PM, Dan Smith wrote: > > Again, nothing new to discuss this time. > > On May 14, we'll be having some Oracle-internal Valhalla meetings and so we'll cancel that one too. I think that will lead to some useful updates for the May 28 meeting. Err, make that the 15th and the 29th. From daniel.smith at oracle.com Sat May 4 00:58:57 2024 From: daniel.smith at oracle.com (Dan Smith) Date: Sat, 4 May 2024 00:58:57 +0000 Subject: Revised JVMS changes for JEP 401 Message-ID: FYI, I've posted an update to the JEP 401 JVMS changes: https://cr.openjdk.org/~dlsmith/jep401/jep401-20240503/specs/value-objects-jvms.html Addresses a variety of small issues raised in the last few months. One notable change is the use of a new exception type, IdentityException, to indicate misuse of value objects, including attempted 'monitorenter' and 'monitorexit'. Another is to clarify the ways in which Preload can be used, at the discretion of implementations. (Still to investigate: ideas about alternative encodings for the Preload attribute.) From forax at univ-mlv.fr Tue May 21 08:09:59 2024 From: forax at univ-mlv.fr (Remi Forax) Date: Tue, 21 May 2024 10:09:59 +0200 (CEST) Subject: It starts with a bang ends with a quote Message-ID: <801143047.26882677.1716278999398.JavaMail.zimbra@univ-eiffel.fr> Hello, I recently tried to convince myself that using a type annotation (the bang '!') was the best way to do type specialization at langage level but I still find it awkward. There are several reasons why using a bang to ask for type specialization does not work well with the rest of the design of value types. The first argument is that value types is a runtime construct, in term of typing and code generation, a value type is undistinguishable from an identity type, only when the code is run, one can tell the difference. On the other hand, a bang is a type construct, a bang change the typechecking (change the type inference) and has a side effect on the generated code. So there is a mismatch here. The obvious problem from that mismatch is that a bang will record if a value type is a value type at typechecking time while the corresponding class may not be a value type at runtime. We have the same problem with the Preload attribute, so it's not a major problem. The second argument is that bang is a use-site declaration (new ArrayList()), unlike a value class which is declared at declaration site. We know that use site declarations make the language harder to use. We tried in the past to not introduce features that uses use-site declaration (const?) or in case of wildcards (aka use site variance), the rational was that not all users are exposed top wildcards, only library devs need to declare them. Using use-site declarations should be avoided if possible. The third argument is that it adds a complexity to the model that we may not need. In a langage like C#, a list of value type is a flatten list, a list of identity type is not flatten, there is no way to ask for a list of value types that is not flatten. One advantage of the bang is that it is easier to retrofit the relationship between a wrapper type and its primitive type, a primitive type like int being (mostly) an Integer!. But wrapper types can be seen as special cases, we may not want all value types to behave like primitive types or wrapper types depending on the user choice. For the parametric VM, I think we should first try to implement a simpler model where all value types (with implicit constructor) are flatten (if the field/array is tagged as such) and only move to a use site model if there are performance issues. Here, I describe the quote model, which is the bang model without use-site declaration. Let's introduce the sigil ^ (quote) that can be used only on a type variable or an array of type variable. A field declaration can use T^ or T^[] as type. When an array is created, new T^[12] can be used otherwise the class of the type argument is not flatten. Collections like the implemntation of List.of() or ArrayList can be retrofitted to create their arrays with a quote, the only problem is that the return value of List.set() can be an empty value type instead of null, but the return value of List.set() is rarely used so it should not be a big issue in practice. Map.get() can return null which is not a problem because T is nullable, only T^ on field is not. What we are loosing here is the - calling convention adaptation may be harder for the VM - wrapping classes like java.lang.Integer, etc should *not* have an implicit constructor, int == Integer+implicit constructor when using List and List has a boxing convertion with List. I think we should try the quote model first, evaluate it before deciding to move or not to the bang model. regards, R?mi From daniel.smith at oracle.com Tue May 21 14:49:30 2024 From: daniel.smith at oracle.com (Dan Smith) Date: Tue, 21 May 2024 14:49:30 +0000 Subject: It starts with a bang ends with a quote In-Reply-To: <801143047.26882677.1716278999398.JavaMail.zimbra@univ-eiffel.fr> References: <801143047.26882677.1716278999398.JavaMail.zimbra@univ-eiffel.fr> Message-ID: On May 21, 2024, at 1:09?AM, Remi Forax wrote: Hello, I recently tried to convince myself that using a type annotation (the bang '!') was the best way to do type specialization at langage level but I still find it awkward. There are several reasons why using a bang to ask for type specialization does not work well with the rest of the design of value types. We've considered lots of different variations on specialization, so to be clear: you're critiquing an approach in which Foo is specialized, while Foo and Foo are not. Is that right? I think we're going to end up with a stronger requirement: that Foo and Foo must *both* be specialized. (My inclination has always been to throw Foo in there, too, but that one is more negotiable.) Why specialize Foo? Because we can often still flatten the storage (we're including some flattening of nullable value class types in JEP 401), and in any case we should always scalarize specialized method signatures for value class types. -------------- next part -------------- An HTML attachment was scrubbed... URL: From forax at univ-mlv.fr Tue May 21 15:29:59 2024 From: forax at univ-mlv.fr (forax at univ-mlv.fr) Date: Tue, 21 May 2024 17:29:59 +0200 (CEST) Subject: It starts with a bang ends with a quote In-Reply-To: References: <801143047.26882677.1716278999398.JavaMail.zimbra@univ-eiffel.fr> Message-ID: <877765788.27455245.1716305399621.JavaMail.zimbra@univ-eiffel.fr> > From: "daniel smith" > To: "Remi Forax" > Cc: "valhalla-spec-experts" > Sent: Tuesday, May 21, 2024 4:49:30 PM > Subject: Re: It starts with a bang ends with a quote >> On May 21, 2024, at 1:09 AM, Remi Forax wrote: >> Hello, >> I recently tried to convince myself that using a type annotation (the bang '!') >> was the best way to do type specialization at langage level but I still find it >> awkward. >> There are several reasons why using a bang to ask for type specialization does >> not work well with the rest of the design of value types. > We've considered lots of different variations on specialization, so to be clear: > you're critiquing an approach in which Foo is specialized, while > Foo and Foo are not. Is that right? Not exactly, I think we do not need Foo at all. > I think we're going to end up with a stronger requirement: that Foo and > Foo must *both* be specialized. (My inclination has always been to throw > Foo in there, too, but that one is more negotiable.) > Why specialize Foo? Because we can often still flatten the storage (we're > including some flattening of nullable value class types in JEP 401), and in any > case we should always scalarize specialized method signatures for value class > types. I will go a step further, by example, in most case an immutable list rejects null, so a list created with ImmutableList via List.of() should be specialized, it's up to the implementation of ImmutableList to decide which kind of storage to use. So it's not something a user should control, thus no List, List is enough. An for the scalarization, i hope that Val + requireNonNull is enough (we can speculate of the fact that a value type is non null). R?mi -------------- next part -------------- An HTML attachment was scrubbed... URL: From ccherlin at gmail.com Tue May 21 21:37:35 2024 From: ccherlin at gmail.com (Clement Cherlin) Date: Tue, 21 May 2024 16:37:35 -0500 Subject: It starts with a bang ends with a quote In-Reply-To: <877765788.27455245.1716305399621.JavaMail.zimbra@univ-eiffel.fr> References: <801143047.26882677.1716278999398.JavaMail.zimbra@univ-eiffel.fr> <877765788.27455245.1716305399621.JavaMail.zimbra@univ-eiffel.fr> Message-ID: On Tue, May 21, 2024 at 10:30?AM wrote: > > > ------------------------------ > > *From: *"daniel smith" > *To: *"Remi Forax" > *Cc: *"valhalla-spec-experts" > *Sent: *Tuesday, May 21, 2024 4:49:30 PM > *Subject: *Re: It starts with a bang ends with a quote > > On May 21, 2024, at 1:09?AM, Remi Forax wrote: > > Hello, > I recently tried to convince myself that using a type annotation (the bang > '!') was the best way to do type specialization at langage level but I > still find it awkward. > > There are several reasons why using a bang to ask for type specialization > does not work well with the rest of the design of value types. > > > We've considered lots of different variations on specialization, so to be > clear: you're critiquing an approach in which Foo is specialized, > while Foo and Foo are not. Is that right? > > > Not exactly, I think we do not need Foo at all. > > > I think we're going to end up with a stronger requirement: that Foo > and Foo must *both* be specialized. (My inclination has always been to > throw Foo in there, too, but that one is more negotiable.) > > Why specialize Foo? Because we can often still flatten the storage > (we're including some flattening of nullable value class types in JEP 401), > and in any case we should always scalarize specialized method signatures > for value class types. > > > I will go a step further, by example, in most case an immutable list > rejects null, so a list created with ImmutableList via List.of() > should be specialized, it's up to the implementation of ImmutableList to > decide which kind of storage to use. So it's not something a user should > control, thus no List, List is enough. An for the scalarization, > i hope that Val + requireNonNull is enough (we can speculate of the fact > that a value type is non null). > > R?mi > I'm concerned that eliminating ! also eliminates a lot of benefits. There is a lot of value in ! other than flattening optimizations: Self-documentation, static analysis and (potentially) JVM-enforced runtime non-nullability guarantees. If there is no T! then List.of() cannot have the static return type List, which it should. I want the ability to refine any type (not just value types) to exclude nulls. Flattening value type instances is a JVM performance feature, and is not the same as the language feature of non-nullability refinement. I don't see there being another way to get the performance feature as a justification for dropping the language feature. Cheers, Clement Cherlin -------------- next part -------------- An HTML attachment was scrubbed... URL: From forax at univ-mlv.fr Wed May 22 09:17:04 2024 From: forax at univ-mlv.fr (Remi Forax) Date: Wed, 22 May 2024 11:17:04 +0200 (CEST) Subject: It starts with a bang ends with a quote In-Reply-To: References: <801143047.26882677.1716278999398.JavaMail.zimbra@univ-eiffel.fr> <877765788.27455245.1716305399621.JavaMail.zimbra@univ-eiffel.fr> Message-ID: <1827712621.28101120.1716369424306.JavaMail.zimbra@univ-eiffel.fr> > From: "Clement Cherlin" > To: "Valhalla Expert Group Observers" > Sent: Tuesday, May 21, 2024 11:37:35 PM > Subject: Re: It starts with a bang ends with a quote > On Tue, May 21, 2024 at 10:30 AM < [ mailto:forax at univ-mlv.fr | > forax at univ-mlv.fr ] > wrote: >>> From: "daniel smith" < [ mailto:daniel.smith at oracle.com | >>> daniel.smith at oracle.com ] > >>> To: "Remi Forax" < [ mailto:forax at univ-mlv.fr | forax at univ-mlv.fr ] > >>> Cc: "valhalla-spec-experts" < [ mailto:valhalla-spec-experts at openjdk.java.net | >>> valhalla-spec-experts at openjdk.java.net ] > >>> Sent: Tuesday, May 21, 2024 4:49:30 PM >>> Subject: Re: It starts with a bang ends with a quote >>>> On May 21, 2024, at 1:09 AM, Remi Forax < [ mailto:forax at univ-mlv.fr | >>>> forax at univ-mlv.fr ] > wrote: >>>> Hello, >>>> I recently tried to convince myself that using a type annotation (the bang '!') >>>> was the best way to do type specialization at langage level but I still find it >>>> awkward. >>>> There are several reasons why using a bang to ask for type specialization does >>>> not work well with the rest of the design of value types. >>> We've considered lots of different variations on specialization, so to be clear: >>> you're critiquing an approach in which Foo is specialized, while >>> Foo and Foo are not. Is that right? >> Not exactly, I think we do not need Foo at all. >>> I think we're going to end up with a stronger requirement: that Foo and >>> Foo must *both* be specialized. (My inclination has always been to throw >>> Foo in there, too, but that one is more negotiable.) >>> Why specialize Foo? Because we can often still flatten the storage (we're >>> including some flattening of nullable value class types in JEP 401), and in any >>> case we should always scalarize specialized method signatures for value class >>> types. >> I will go a step further, by example, in most case an immutable list rejects >> null, so a list created with ImmutableList via List.of() should be >> specialized, it's up to the implementation of ImmutableList to decide which >> kind of storage to use. So it's not something a user should control, thus no >> List, List is enough. An for the scalarization, i hope that Val + >> requireNonNull is enough (we can speculate of the fact that a value type is non >> null). >> R?mi > I'm concerned that eliminating ! also eliminates a lot of benefits. There is a > lot of value in ! other than flattening optimizations: Self-documentation, > static analysis and (potentially) JVM-enforced runtime non-nullability > guarantees. If there is no T! then List.of() cannot have the static return type > List, which it should. > I want the ability to refine any type (not just value types) to exclude nulls. > Flattening value type instances is a JVM performance feature, and is not the > same as the language feature of non-nullability refinement. I don't see there > being another way to get the performance feature as a justification for > dropping the language feature. Hello Clement, currently, T! only have an effect on value types, you can not write String!. Tracking nulls, in the type system and/or inserting nullchecks is something useful, but it's a separate discussion. BTW, i've recently tested the combo JSpecify annotations + ErrorProne NullAway which is quite nice for the type checking part. > Cheers, > Clement Cherlin R?mi -------------- next part -------------- An HTML attachment was scrubbed... URL: From cay.horstmann at gmail.com Sat May 25 16:58:48 2024 From: cay.horstmann at gmail.com (Cay Horstmann) Date: Sat, 25 May 2024 18:58:48 +0200 Subject: How to observe a flat array? Message-ID: <528af070-4bc9-44f9-aab2-0bd1b7b2a0f3@gmail.com> I just tried the following after building https://github.com/openjdk/valhalla: @ImplicitlyConstructible @LooselyConsistentValue value record Point(double x, double y) { public Point transform() { return new Point(x + Math.random() - 0.5, y + Math.random() - 0.5); } } public class Points { static int NPOINTS = 100_000_000; public static void main(String[] args) { Point[] path = (Point[]) ValueClass.newNullRestrictedArray(Point.class, NPOINTS); for (int i = 1; i < path.length; i++) { path[i] = path[i - 1].transform(); } System.out.println(path[path.length - 1]); try { Thread.sleep(60_000); } catch (Exception e) { e.printStackTrace(); } } } Running jcmd withvalhalla.Points GC.class_histogram shows num #instances #bytes class name (module) ------------------------------------------------------- 1: 100000000 3200000000 withvalhalla.Point 2: 1 400000016 [Lwithvalhalla.Point; That doesn't look like a flattened array, but like an array with NPOINTS references. Do I need to wait for the JIT to kick in? Or is this not yet implemented? Thanks, Cay -- Cay S. Horstmann | https://horstmann.com