From daniel.smith at oracle.com Mon Jun 3 19:00:16 2024 From: daniel.smith at oracle.com (Dan Smith) Date: Mon, 3 Jun 2024 19:00:16 +0000 Subject: Updated specifications Message-ID: I've posted updated specifications for JEP 401 here: https://cr.openjdk.org/~dlsmith/jep401/jep401-20240603/specs/value-objects-jls.html https://cr.openjdk.org/~dlsmith/jep401/jep401-20240603/specs/value-objects-jvms.html These are intended to address all the needs of JEP 401, and I don't expect many further revisions?but as always, happy to hear any feedback. From mcnepp02 at googlemail.com Tue Jun 4 06:57:16 2024 From: mcnepp02 at googlemail.com (Gernot Neppert) Date: Tue, 4 Jun 2024 08:57:16 +0200 Subject: Updated specifications In-Reply-To: References: Message-ID: Hi Dan, these paragraphs seem contradictionary with regards to the allowed superclasses of value-classes: 8.1.1.5 forbids any identity-superclass other than Object, while 8.10 states that the superclass of every (value-)record-class is (the identity-class) Record. To me, it looks as if 8.1.1.5 should mention Record as another possible implicit superclass. Regards, Gernot > Am 03.06.2024 um 21:00 schrieb Dan Smith : > > ?I've posted updated specifications for JEP 401 here: > > https://cr.openjdk.org/~dlsmith/jep401/jep401-20240603/specs/value-objects-jls.html > https://cr.openjdk.org/~dlsmith/jep401/jep401-20240603/specs/value-objects-jvms.html > > These are intended to address all the needs of JEP 401, and I don't expect many further revisions?but as always, happy to hear any feedback. > -------------- next part -------------- An HTML attachment was scrubbed... URL: From dan.heidinga at oracle.com Wed Jun 5 16:21:18 2024 From: dan.heidinga at oracle.com (Dan Heidinga) Date: Wed, 5 Jun 2024 16:21:18 +0000 Subject: Updated specifications In-Reply-To: References: Message-ID: Thanks for making the update from Preload to LoadableDescriptors. It cleans up the spec a lot. I have concerns about the changes to 5.4 related to loading classes. As discussed at the offsite meeting, from an implementation perspective, we don?t want to introduce new rules that allow loading of arbitrary classes at any point during linking. There are already rules in place about further execution being driven by the invocation of the main method (JVMS 5.2) and the linking activities driven by its execution. Introducing new rules that legitimize other loading strategies are outside the remit of Valhalla and are unnecessary for our purposes. The original 5.4 states ?Linking also involves resolution of symbolic references in the class or interface, though not necessarily at the same time as the class or interface is verified and prepared.? which already allows for loading of necessary classes. The new sentence ?All of these linking activities may involve the loading of other classes and interfaces mentioned in the constant pool of the current class or interface.? unnecessary widens what and when loading can occur and opens doors I don?t think we need or want opened. I think this change should also be reverted: ?, (and, because of recursion, loading) including the loading of other classes,? as it broadens the loading behaviour beyond what the original struck thru clause meant. The new clause: >If a class being linked has a LoadableDescriptors attribute (4.7.32), then during any phase of linking, a Java Virtual Machine implementation may optionally load any of the classes or interfaces mentioned by the entries of the descriptors array of the LoadableDescriptors attribute. Any exception that is thrown as a result of failure to load the class or interface must be ignored and discarded. sufficiently covers the behaviour we want to add in Valhalla. Thanks, --Dan From: valhalla-spec-experts on behalf of Dan Smith Date: Monday, June 3, 2024 at 3:00?PM To: valhalla-spec-experts Subject: Updated specifications I've posted updated specifications for JEP 401 here: https://cr.openjdk.org/~dlsmith/jep401/jep401-20240603/specs/value-objects-jls.html https://cr.openjdk.org/~dlsmith/jep401/jep401-20240603/specs/value-objects-jvms.html These are intended to address all the needs of JEP 401, and I don't expect many further revisions?but as always, happy to hear any feedback. -------------- next part -------------- An HTML attachment was scrubbed... URL: From daniel.smith at oracle.com Wed Jun 5 17:42:05 2024 From: daniel.smith at oracle.com (Dan Smith) Date: Wed, 5 Jun 2024 17:42:05 +0000 Subject: Updated specifications In-Reply-To: References: Message-ID: <74B50098-7983-4D2B-8995-247A83182D70@oracle.com> > On Jun 5, 2024, at 9:21?AM, Dan Heidinga wrote: > > Thanks for making the update from Preload to LoadableDescriptors. It cleans up the spec a lot. > > I have concerns about the changes to 5.4 related to loading classes. As discussed at the offsite meeting, from an implementation perspective, we don?t want to introduce new rules that allow loading of arbitrary classes at any point during linking. There are already rules in place about further execution being driven by the invocation of the main method (JVMS 5.2) and the linking activities driven by its execution. Introducing new rules that legitimize other loading strategies are outside the remit of Valhalla and are unnecessary for our purposes. Not the intent?I did leave in these rephrasings that, on review, didn't look like they were weighing in on this issue. > The original 5.4 states ?Linking also involves resolution of symbolic references in the class or interface, though not necessarily at the same time as the class or interface is verified and prepared.? which already allows for loading of necessary classes. The new sentence ?All of these linking activities may involve the loading of other classes and interfaces mentioned in the constant pool of the current class or interface.? unnecessary widens what and when loading can occur and opens doors I don?t think we need or want opened. The clarification I wanted to make, in particular, is that verification can lead to loading, independently from resolution. Would it help to say "the **specified** loading of other classes and interfaces"? > I think this change should also be reverted: ?, (and, because of recursion, loading) including the loading of other classes,? as it broadens the loading behaviour beyond what the original struck thru clause meant. I just thought the "because of recursion" felt very tailored to constant resolution, again ignoring verification-time loading. Given the previous sentence, I'd actually be happy to just delete this aside about loading entirely. This paragraph and bulleted list really doesn't need to be concerned with loading (of other classes) at all. From dan.heidinga at oracle.com Wed Jun 5 17:56:06 2024 From: dan.heidinga at oracle.com (Dan Heidinga) Date: Wed, 5 Jun 2024 17:56:06 +0000 Subject: Updated specifications In-Reply-To: <74B50098-7983-4D2B-8995-247A83182D70@oracle.com> References: <74B50098-7983-4D2B-8995-247A83182D70@oracle.com> Message-ID: From: Dan Smith Date: Wednesday, June 5, 2024 at 1:42?PM To: Dan Heidinga Cc: valhalla-spec-experts Subject: Re: Updated specifications > On Jun 5, 2024, at 9:21?AM, Dan Heidinga wrote: > > Thanks for making the update from Preload to LoadableDescriptors. It cleans up the spec a lot. > > I have concerns about the changes to 5.4 related to loading classes. As discussed at the offsite meeting, from an implementation perspective, we don?t want to introduce new rules that allow loading of arbitrary classes at any point during linking. There are already rules in place about further execution being driven by the invocation of the main method (JVMS 5.2) and the linking activities driven by its execution. Introducing new rules that legitimize other loading strategies are outside the remit of Valhalla and are unnecessary for our purposes. Not the intent?I did leave in these rephrasings that, on review, didn't look like they were weighing in on this issue. I would prefer to revert these additions as it introduces an ambiguity into spec ? some loading may be driven by resolution while the new sentence implies additional unstated reasons classes may be loaded from the constant pool. > The original 5.4 states ?Linking also involves resolution of symbolic references in the class or interface, though not necessarily at the same time as the class or interface is verified and prepared.? which already allows for loading of necessary classes. The new sentence ?All of these linking activities may involve the loading of other classes and interfaces mentioned in the constant pool of the current class or interface.? unnecessary widens what and when loading can occur and opens doors I don?t think we need or want opened. The clarification I wanted to make, in particular, is that verification can lead to loading, independently from resolution. Would it help to say "the **specified** loading of other classes and interfaces"? Class loading due to verification is already covered in 5.4.1 where it the spec says: ?Verification may cause additional classes and interfaces to be loaded??. There is a state machine in class loading that goes from loaded > verified > prepared > initialized. Linking is a longer stage that spans from verified to unloaded as linking can continue throughout execution when using a lazy strategy. Since linking includes verification and preparation I don?t think we need additional clarification in 5.4 as 5.4.1 covers it already. > I think this change should also be reverted: ?, (and, because of recursion, loading) including the loading of other classes,? as it broadens the loading behaviour beyond what the original struck thru clause meant. I just thought the "because of recursion" felt very tailored to constant resolution, again ignoring verification-time loading. Given the previous sentence, I'd actually be happy to just delete this aside about loading entirely. This paragraph and bulleted list really doesn't need to be concerned with loading (of other classes) at all. Deleting both the original ?because of recursion? and the new ?including the loading of other classes? text works for me. --Dan -------------- next part -------------- An HTML attachment was scrubbed... URL: From daniel.smith at oracle.com Wed Jun 5 17:57:58 2024 From: daniel.smith at oracle.com (Dan Smith) Date: Wed, 5 Jun 2024 17:57:58 +0000 Subject: Updated specifications In-Reply-To: <74B50098-7983-4D2B-8995-247A83182D70@oracle.com> References: <74B50098-7983-4D2B-8995-247A83182D70@oracle.com> Message-ID: > On Jun 5, 2024, at 10:42?AM, Dan Smith wrote: > > The clarification I wanted to make, in particular, is that verification can lead to loading, independently from resolution. Oh, and also: that LoadableDescriptors can now lead to loading "during any phase of linking". This is meant to be a general sentence that just says, as an introduction to the concept of linking, that sometimes specified linking activities can lead to further loading. From daniel.smith at oracle.com Wed Jun 5 18:07:45 2024 From: daniel.smith at oracle.com (Dan Smith) Date: Wed, 5 Jun 2024 18:07:45 +0000 Subject: Updated specifications In-Reply-To: References: <74B50098-7983-4D2B-8995-247A83182D70@oracle.com> Message-ID: <235B9CFB-AB80-4C12-B4C1-85FC74637909@oracle.com> > On Jun 5, 2024, at 10:56?AM, Dan Heidinga wrote: > >> Given the previous sentence, I'd actually be happy to just delete this aside about loading entirely. This paragraph and bulleted list really doesn't need to be concerned with loading (of other classes) at all. > > Deleting both the original ?because of recursion? and the new ?including the loading of other classes? text works for me. I'd also like to delete "other than the recursive loading of related classes and interfaces specified in 5.3.5" That's a holdover from when I was viewing all loading as a kind of "linking activity". But we don't want to muddy the waters. The recursive loading occuring in 5.3.5 is just a specified part of the loading process. From ccherlin at gmail.com Thu Jun 6 20:36:32 2024 From: ccherlin at gmail.com (Clement Cherlin) Date: Thu, 6 Jun 2024 15:36:32 -0500 Subject: Updated specifications In-Reply-To: References: Message-ID: Hi Gernot, I believe that the contradiction is resolved if Record (which is abstract) is also declared as a value class. While the spec doesn't state explicitly that an identity class can extend an abstract value class, I think that has to be the case if a Record can be either value or identity, and also for the following binary compatibility statement to be meaningful: Modifying an abstract or final identity class to be a value class does not > break compatibility with pre-existing binaries. If an existing abstract identity class (such as Record) has identity subclasses, and it does not break compatibility to modify Record to be a value class, then those identity subclasses must continue to function with an abstract value superclass. I think it would be clearer if the spec were to explicitly state the following: * An identity class is permitted to extend an abstract value superclass. * The abstract class java.lang.Record must be declared as a value class. Cheers, Clement On Tue, Jun 4, 2024 at 1:58?AM Gernot Neppert wrote: > > > Hi Dan, > > these paragraphs seem contradictionary with regards to the allowed > superclasses of value-classes: > 8.1.1.5 forbids any identity-superclass other than Object, while 8.10 > states that the superclass of every (value-)record-class is (the > identity-class) Record. > > To me, it looks as if 8.1.1.5 should mention Record as another possible > implicit superclass. > > Regards, Gernot > > > > > Am 03.06.2024 um 21:00 schrieb Dan Smith : > > ?I've posted updated specifications for JEP 401 here: > > > https://cr.openjdk.org/~dlsmith/jep401/jep401-20240603/specs/value-objects-jls.html > > https://cr.openjdk.org/~dlsmith/jep401/jep401-20240603/specs/value-objects-jvms.html > > These are intended to address all the needs of JEP 401, and I don't expect > many further revisions?but as always, happy to hear any feedback. > > -------------- next part -------------- An HTML attachment was scrubbed... URL: From daniel.smith at oracle.com Wed Jun 12 15:12:06 2024 From: daniel.smith at oracle.com (Dan Smith) Date: Wed, 12 Jun 2024 15:12:06 +0000 Subject: EG meeting *canceled*, 2024-06-12 Message-ID: <45910A30-BCD2-4E43-96C1-B1470ED63723@oracle.com> I posted an incremental update to the specifications last week, but otherwise no new activity here. Let's cancel today. From daniel.smith at oracle.com Sat Jun 22 00:09:08 2024 From: daniel.smith at oracle.com (Dan Smith) Date: Sat, 22 Jun 2024 00:09:08 +0000 Subject: Updated specifications In-Reply-To: References: Message-ID: <6CD2399A-DC7A-49B7-8051-B816E28E1CA4@oracle.com> > On Jun 3, 2024, at 12:00?PM, Dan Smith wrote: > > I've posted updated specifications for JEP 401 here: > > https://cr.openjdk.org/~dlsmith/jep401/jep401-20240603/specs/value-objects-jls.html > https://cr.openjdk.org/~dlsmith/jep401/jep401-20240603/specs/value-objects-jvms.html > > These are intended to address all the needs of JEP 401, and I don't expect many further revisions?but as always, happy to hear any feedback. Refreshed to address the comments in this thread, and to include the revised Flexible Constructor Bodies JLS document. https://cr.openjdk.org/~dlsmith/jep401/jep401-20240621/specs/value-objects-jls.html https://cr.openjdk.org/~dlsmith/jep401/jep401-20240621/specs/value-objects-jvms.html From dan.heidinga at oracle.com Mon Jun 24 12:19:21 2024 From: dan.heidinga at oracle.com (Dan Heidinga) Date: Mon, 24 Jun 2024 12:19:21 +0000 Subject: Updated specifications In-Reply-To: <6CD2399A-DC7A-49B7-8051-B816E28E1CA4@oracle.com> References: <6CD2399A-DC7A-49B7-8051-B816E28E1CA4@oracle.com> Message-ID: I?m still concerned about the sentence in 5.4 that says: ?Linking activities may sometimes require the loading of additional classes.? as it can be read to support arbitrary class loads during linking. David Holmes and I have been having a related discussion in https://bugs.openjdk.org/browse/JDK-8334324 about similar topics and this sentence would change the meaning of the spec and tilt those discussions. The reason we have LoadableDescriptors is threefold ? to give permission for arbitrary loads, to hint which arbitrary loads may be fruitful, and to allow ignoring errors. If there?s something in that sentence to tie it back to ?loading in support of linking activities? then I?d be ok with the sentence. The original used the wording ?because of recursion? so maybe reusing that would be sufficient: ?Linking activities may, because of recursion, sometimes require the loading of additional classes.? Without something like the ?recursion? rationale, I think the spec is clearer without the new sentence. --Dan From: valhalla-spec-experts on behalf of Dan Smith Date: Friday, June 21, 2024 at 8:09?PM To: valhalla-spec-experts Subject: Re: Updated specifications > On Jun 3, 2024, at 12:00?PM, Dan Smith wrote: > > I've posted updated specifications for JEP 401 here: > > https://cr.openjdk.org/~dlsmith/jep401/jep401-20240603/specs/value-objects-jls.html > https://cr.openjdk.org/~dlsmith/jep401/jep401-20240603/specs/value-objects-jvms.html > > These are intended to address all the needs of JEP 401, and I don't expect many further revisions?but as always, happy to hear any feedback. Refreshed to address the comments in this thread, and to include the revised Flexible Constructor Bodies JLS document. https://cr.openjdk.org/~dlsmith/jep401/jep401-20240621/specs/value-objects-jls.html https://cr.openjdk.org/~dlsmith/jep401/jep401-20240621/specs/value-objects-jvms.html -------------- next part -------------- An HTML attachment was scrubbed... URL: From daniel.smith at oracle.com Mon Jun 24 18:46:59 2024 From: daniel.smith at oracle.com (Dan Smith) Date: Mon, 24 Jun 2024 18:46:59 +0000 Subject: Updated specifications In-Reply-To: References: <6CD2399A-DC7A-49B7-8051-B816E28E1CA4@oracle.com> Message-ID: > On Jun 24, 2024, at 5:19?AM, Dan Heidinga wrote: > > I?m still concerned about the sentence in 5.4 that says: ?Linking activities may sometimes require the loading of additional classes.? as it can be read to support arbitrary class loads during linking. David Holmes and I have been having a related discussion in https://bugs.openjdk.org/browse/JDK-8334324 about similar topics and this sentence would change the meaning of the spec and tilt those discussions. Ah, thanks for the reference to that issue. I thought we could rephrase to help clean up the ambiguity, but it's clear that it's still a live issue to just figure out what behavior we want to disambiguate to (and whether various longstanding HotSpot behaviors need to change). That's not something I want to keep tying Valhalla to, so I'll spin this off as a separate issue. I've filed a bug: https://bugs.openjdk.org/browse/JDK-8334888 And here's the refreshed JVMS change doc: https://cr.openjdk.org/~dlsmith/jep401/jep401-20240624/specs/value-objects-jvms.html From dan.heidinga at oracle.com Mon Jun 24 19:11:01 2024 From: dan.heidinga at oracle.com (Dan Heidinga) Date: Mon, 24 Jun 2024 19:11:01 +0000 Subject: Updated specifications In-Reply-To: References: <6CD2399A-DC7A-49B7-8051-B816E28E1CA4@oracle.com> Message-ID: Thanks Dan. That looks good to me. --Dan From: Dan Smith Date: Monday, June 24, 2024 at 2:47?PM To: Dan Heidinga Cc: valhalla-spec-experts Subject: Re: Updated specifications > On Jun 24, 2024, at 5:19?AM, Dan Heidinga wrote: > > I?m still concerned about the sentence in 5.4 that says: ?Linking activities may sometimes require the loading of additional classes.? as it can be read to support arbitrary class loads during linking. David Holmes and I have been having a related discussion in https://bugs.openjdk.org/browse/JDK-8334324 about similar topics and this sentence would change the meaning of the spec and tilt those discussions. Ah, thanks for the reference to that issue. I thought we could rephrase to help clean up the ambiguity, but it's clear that it's still a live issue to just figure out what behavior we want to disambiguate to (and whether various longstanding HotSpot behaviors need to change). That's not something I want to keep tying Valhalla to, so I'll spin this off as a separate issue. I've filed a bug: https://bugs.openjdk.org/browse/JDK-8334888 And here's the refreshed JVMS change doc: https://cr.openjdk.org/~dlsmith/jep401/jep401-20240624/specs/value-objects-jvms.html -------------- next part -------------- An HTML attachment was scrubbed... URL: From daniel.smith at oracle.com Tue Jun 25 16:40:51 2024 From: daniel.smith at oracle.com (Dan Smith) Date: Tue, 25 Jun 2024 16:40:51 +0000 Subject: EG meeting *canceled*, 2024-06-26 Message-ID: I've got a conflict tomorrow, sorry! I don't see any pressing topics, so let's just cancel this time. At Oracle, we're making progress towards a refreshed EA release, hope to get that completed in the next few weeks. For the next meeting: if anybody has areas of concern you'd like to discuss, please send an email, and we can address it.