From daniel.smith at oracle.com Fri Mar 2 00:43:51 2018 From: daniel.smith at oracle.com (Dan Smith) Date: Thu, 1 Mar 2018 17:43:51 -0700 Subject: A "RecursiveConstants" attribute In-Reply-To: <6BDD2D9A-1399-46ED-960C-6816C310FAAF@oracle.com> References: <131B1F8D-F49C-47F8-BE7C-A660CBE1FCB5@oracle.com> <2CEA5EE3-6F51-4806-9CA5-2BAFCF0620E8@oracle.com> <95f19422-86a4-115b-eae7-d274ab57e072@oracle.com> <60BB9395-3B8B-4901-A8AD-99B3C209A005@oracle.com> <29CA13B1-7A8B-446D-8235-98CBE978AB97@oracle.com> <75563174.2472564.1518865303213.JavaMail.zimbra@u-pem.fr> <6BDD2D9A-1399-46ED-960C-6816C310FAAF@oracle.com> Message-ID: > On Feb 23, 2018, at 4:47 PM, Dan Smith wrote: > > I'll ask our code gen experts about what they'd expect from Dynamic, and whether it's easy to assume they always point in one direction or the other. Feedback from Maurizio: - javac prototypes that use condy will emit static arguments before the condy (he thinks), so all references will be backward - It's not hard to tweak the code to generate constants in whatever order we prefer Should be safe to expect the same from Eclipse. ?Dan -------------- next part -------------- An HTML attachment was scrubbed... URL: From daniel.smith at oracle.com Mon Mar 5 19:41:16 2018 From: daniel.smith at oracle.com (Dan Smith) Date: Mon, 5 Mar 2018 12:41:16 -0700 Subject: CONSTANT_Dynamic bootstrap signature restriction Message-ID: <973DED2E-5274-40F3-B226-9F65EC832E34@oracle.com> In discussions about future directions for CONSTANT_Dynamic, we've decided it would be helpful to restrict the set of legal bootstrap signatures. The first parameter type would be required to be declared with type MethodHandles.Lookup. See [1] for further discussion. Here's the proposed spec change: -------- 1. _R_ gives a symbolic reference to a bootstrap method handle. The bootstrap method handle is resolved ([5.4.3.5]) to obtain a `reference` to an instance of `java.lang.invoke.MethodHandle`. Any exception that can be thrown as a result of failure of resolution of a symbolic reference to a method handle can be thrown in this step. **If _R_ is a symbolic reference to a dynamically-computed constant, then it must be the case that the first parameter type of the `java.lang.invoke.MethodType` of the `java.lang.invoke.MethodHandle` is a `Class` representing the class `java.lang.invoke.MethodHandles$Lookup`. If not, resolution fails with a `BootstrapMethodError`.** > **In contrast, for historical reasons, a dynamically-computed call site may be resolved using a bootstrap method handle whose first parameter type is `Object` or some other compatible type, as determined by the `invokeWithArguments` invocation described below.** -------- ?Dan [1] https://bugs.openjdk.java.net/browse/JDK-8199051 From Daniel_Heidinga at ca.ibm.com Mon Mar 5 19:56:50 2018 From: Daniel_Heidinga at ca.ibm.com (Daniel Heidinga) Date: Mon, 5 Mar 2018 19:56:50 +0000 Subject: CONSTANT_Dynamic bootstrap signature restriction In-Reply-To: <973DED2E-5274-40F3-B226-9F65EC832E34@oracle.com> References: <973DED2E-5274-40F3-B226-9F65EC832E34@oracle.com> Message-ID: > >In discussions about future directions for CONSTANT_Dynamic, we've >decided it would be helpful to restrict the set of legal bootstrap >signatures. The first parameter type would be required to be declared >with type MethodHandles.Lookup. Dan, can you expand on why this restriction is helpful? It helps when evaluating a specification to have the rationale for the changes - both for the EG and the observers. Thanks, --Dan From daniel.smith at oracle.com Tue Mar 6 00:09:10 2018 From: daniel.smith at oracle.com (Dan Smith) Date: Mon, 5 Mar 2018 17:09:10 -0700 Subject: CONSTANT_Dynamic bootstrap signature restriction In-Reply-To: References: <973DED2E-5274-40F3-B226-9F65EC832E34@oracle.com> Message-ID: <1992DC79-40B7-4EA7-9CC5-D5C060A73010@oracle.com> > On Mar 5, 2018, at 12:56 PM, Daniel Heidinga wrote: >> >> In discussions about future directions for CONSTANT_Dynamic, we've >> decided it would be helpful to restrict the set of legal bootstrap >> signatures. The first parameter type would be required to be declared >> with type MethodHandles.Lookup. > > Dan, can you expand on why this restriction is helpful? It helps when > evaluating a specification to have the rationale for the changes - both > for the EG and the observers. We're considering, for the future, an alternative style of bootstrap invocation in which no metadata (Lookup, name, and type) gets passed. This allows any old method, field, or constructor to act as a bootstrap. In particular, it provides a clean way to map from a live object to a constructor/factory call that will create the object, without having to write dedicated bootstrap code. The idea is that the first parameter type of the method handle acts as a key to indicate the invocation style. The Lookup type indicates the traditional style. This might not pan out, and if so we can drop the error check and return to where we were. But it seems promising, and we don't want to get stuck in 11 making compatibility promises about the interpretation of things like 'bootstrap(Object... args)'. ?Dan From brian.goetz at oracle.com Tue Mar 6 21:34:13 2018 From: brian.goetz at oracle.com (Brian Goetz) Date: Tue, 6 Mar 2018 16:34:13 -0500 Subject: CONSTANT_Dynamic bootstrap signature restriction In-Reply-To: <1992DC79-40B7-4EA7-9CC5-D5C060A73010@oracle.com> References: <973DED2E-5274-40F3-B226-9F65EC832E34@oracle.com> <1992DC79-40B7-4EA7-9CC5-D5C060A73010@oracle.com> Message-ID: <0ad7e7c1-f5d9-2fff-dc4b-1741ab1ec32a@oracle.com> To add to this; we've been building a library which makes extensive use of condy, and we've found that we have to write many factory methods two ways, one as an ordinary factory method and one as a bootstrap which generally just calls the regular factory.? It would reduce duplication both in the library and in the classfile to allow an ordinary factory method to be used as a bootstrap, if you don't care about the metadata parameters (lookup, name, type.)? Turns out this condition is quite common for abstractions that want to support self-condyization. On 3/5/2018 7:09 PM, Dan Smith wrote: >> On Mar 5, 2018, at 12:56 PM, Daniel Heidinga wrote: >>> In discussions about future directions for CONSTANT_Dynamic, we've >>> decided it would be helpful to restrict the set of legal bootstrap >>> signatures. The first parameter type would be required to be declared >>> with type MethodHandles.Lookup. >> Dan, can you expand on why this restriction is helpful? It helps when >> evaluating a specification to have the rationale for the changes - both >> for the EG and the observers. > We're considering, for the future, an alternative style of bootstrap invocation in which no metadata (Lookup, name, and type) gets passed. This allows any old method, field, or constructor to act as a bootstrap. In particular, it provides a clean way to map from a live object to a constructor/factory call that will create the object, without having to write dedicated bootstrap code. > > The idea is that the first parameter type of the method handle acts as a key to indicate the invocation style. The Lookup type indicates the traditional style. > > This might not pan out, and if so we can drop the error check and return to where we were. But it seems promising, and we don't want to get stuck in 11 making compatibility promises about the interpretation of things like 'bootstrap(Object... args)'. > > ?Dan From david.holmes at oracle.com Wed Mar 7 06:12:38 2018 From: david.holmes at oracle.com (David Holmes) Date: Wed, 7 Mar 2018 16:12:38 +1000 Subject: Nestmates: JEP 181 CSR request is ready for review Message-ID: The Nestmates CSR request: https://bugs.openjdk.java.net/browse/JDK-8197445 has been prepared by Dan Smith and myself. Before Proposing this CSR request it needs to have Reviewers add themselves to it. (The first reviewer will need to edit the issue to enter their OpenJDK user name in the "Reviewed by" field. Subsequent reviewers can simply click on the "Reviewed by" field in the "People" section and add their user name. The CSR contains links to all the updated specification documents, all of which have been previously sent out for review/comment to the EG (and observers). Thanks, David From forax at univ-mlv.fr Wed Mar 7 14:48:46 2018 From: forax at univ-mlv.fr (Remi Forax) Date: Wed, 7 Mar 2018 15:48:46 +0100 (CET) Subject: CONSTANT_Dynamic bootstrap signature restriction In-Reply-To: <0ad7e7c1-f5d9-2fff-dc4b-1741ab1ec32a@oracle.com> References: <973DED2E-5274-40F3-B226-9F65EC832E34@oracle.com> <1992DC79-40B7-4EA7-9CC5-D5C060A73010@oracle.com> <0ad7e7c1-f5d9-2fff-dc4b-1741ab1ec32a@oracle.com> Message-ID: <1941514191.1222604.1520434126520.JavaMail.zimbra@u-pem.fr> Daniel (S), Brian, i think your view on this subject is biased by the fact that you built that library. While the name and the type of a condy are not strictly necessary because if you have one bsm by constant, you know the type, you still need the lookup argument, apart if you are building a library that only construct constants that are in the same module than their bsms. Once you have user defined methods/constructors to call to construct the constant, you can not skip the lookup parameter. And i will re-use the argument than Brian use rightly about java.lang.invoke, not a lot of people will write BSMs, so modifying an already complex API call (callsite info * lazy loading of constants * conversion of bsm arguments * varargs) to take care of hiding potentially unused arguments only for few users does not worth the added complexity. > This might not pan out, and if so we can drop the error check and return to where we were. > But it seems promising, and we don't want to get stuck in 11 making compatibility promises > about the interpretation of things like 'bootstrap(Object... args)'. I think it's too late for that, once we had said that the bsm is called with methodhandle.invoke (or more recently invokeWithArguments), bootstrap(Object... args) is already a valid construct. regards, R?mi ----- Mail original ----- > De: "Brian Goetz" > ?: "daniel smith" , "Daniel Heidinga" > Cc: "valhalla-spec-experts" > Envoy?: Mardi 6 Mars 2018 22:34:13 > Objet: Re: CONSTANT_Dynamic bootstrap signature restriction > To add to this; we've been building a library which makes extensive use > of condy, and we've found that we have to write many factory methods two > ways, one as an ordinary factory method and one as a bootstrap which > generally just calls the regular factory.? It would reduce duplication > both in the library and in the classfile to allow an ordinary factory > method to be used as a bootstrap, if you don't care about the metadata > parameters (lookup, name, type.)? Turns out this condition is quite > common for abstractions that want to support self-condyization. > > On 3/5/2018 7:09 PM, Dan Smith wrote: >>> On Mar 5, 2018, at 12:56 PM, Daniel Heidinga wrote: >>>> In discussions about future directions for CONSTANT_Dynamic, we've >>>> decided it would be helpful to restrict the set of legal bootstrap >>>> signatures. The first parameter type would be required to be declared >>>> with type MethodHandles.Lookup. >>> Dan, can you expand on why this restriction is helpful? It helps when >>> evaluating a specification to have the rationale for the changes - both >>> for the EG and the observers. >> We're considering, for the future, an alternative style of bootstrap invocation >> in which no metadata (Lookup, name, and type) gets passed. This allows any old >> method, field, or constructor to act as a bootstrap. In particular, it provides >> a clean way to map from a live object to a constructor/factory call that will >> create the object, without having to write dedicated bootstrap code. >> >> The idea is that the first parameter type of the method handle acts as a key to >> indicate the invocation style. The Lookup type indicates the traditional style. >> >> This might not pan out, and if so we can drop the error check and return to >> where we were. But it seems promising, and we don't want to get stuck in 11 >> making compatibility promises about the interpretation of things like >> 'bootstrap(Object... args)'. >> > > ?Dan From brian.goetz at oracle.com Wed Mar 7 18:28:00 2018 From: brian.goetz at oracle.com (Brian Goetz) Date: Wed, 7 Mar 2018 13:28:00 -0500 Subject: CONSTANT_Dynamic bootstrap signature restriction In-Reply-To: <1941514191.1222604.1520434126520.JavaMail.zimbra@u-pem.fr> References: <973DED2E-5274-40F3-B226-9F65EC832E34@oracle.com> <1992DC79-40B7-4EA7-9CC5-D5C060A73010@oracle.com> <0ad7e7c1-f5d9-2fff-dc4b-1741ab1ec32a@oracle.com> <1941514191.1222604.1520434126520.JavaMail.zimbra@u-pem.fr> Message-ID: > Daniel (S), Brian, > i think your view on this subject is biased by the fact that you built that library. I can understand why you'd think that, but allow me to correct.? My view is biased by the fact that I built the _first_ such library, and it was pretty annoying, and I want to save future programmers from this unnecessary annoyance.? And that we're working on language support that virtually guarantees that others will want to write similar Java libraries.? If this were just about compilers emitting bytecode, I wouldn't care. > And i will re-use the argument than Brian use rightly about java.lang.invoke, not a lot of people will write BSMs, so modifying an already complex API call (callsite info * lazy loading of constants * conversion of bsm arguments * varargs) to take care of hiding potentially unused arguments only for few users does not worth the added complexity. I am saying that I imagine a future where the number of people writing BSMs for condy is at least 100x bigger than it has been historically.? Again, if I thought this was just about me and you and Charlie, I wouldn't care.? But I don't think that's the case here. From karen.kinnear at oracle.com Wed Mar 7 19:47:23 2018 From: karen.kinnear at oracle.com (Karen Kinnear) Date: Wed, 7 Mar 2018 14:47:23 -0500 Subject: Nestmates: JEP 181 CSR request is ready for review In-Reply-To: References: Message-ID: David, Thank you so much for doing this. Very clear description. I marked this as ?Reviewed by" A minor review question: 1. Compatibility risk: Would it make sense to add one more note: Classes in the same package as an existing inner/outer class which took advantage of javac-generated package private bridges to allow inner/outer class access to private members, will now receive an IllegalAccessError. This is an intentional tightening of security for private member access. thanks, Karen > On Mar 7, 2018, at 1:12 AM, David Holmes wrote: > > The Nestmates CSR request: > > https://bugs.openjdk.java.net/browse/JDK-8197445 > > has been prepared by Dan Smith and myself. Before Proposing this CSR request it needs to have Reviewers add themselves to it. > > (The first reviewer will need to edit the issue to enter their OpenJDK user name in the "Reviewed by" field. Subsequent reviewers can simply click on the "Reviewed by" field in the "People" section and add their user name. > > The CSR contains links to all the updated specification documents, all of which have been previously sent out for review/comment to the EG (and observers). > > Thanks, > David From mandy.chung at oracle.com Wed Mar 7 20:12:35 2018 From: mandy.chung at oracle.com (mandy chung) Date: Wed, 7 Mar 2018 12:12:35 -0800 Subject: Nestmates: JEP 181 CSR request is ready for review In-Reply-To: References: Message-ID: Hi David, I'm reviewing the core reflection and j.l.invoke spec change. I think Class::getNestHost and Class::getNestMembers should do a security permission check as performed in other method e.g. getEnclosingClass. ???? * @throws SecurityException ???? *???????? If a security manager, s, is present and ???? *???????? the caller's class loader is not the same as or an ???? *???????? ancestor of the class loader for the current class and ???? *???????? invocation of {@link SecurityManager#checkPackageAccess ???? *???????? s.checkPackageAccess()} denies access to the package ???? *???????? of this class ???? * I suggest to make @apiNote in Class::getNestHost as just part of javadoc. It can define a section like "Nest Membership" that can be referenced by Lookup class spec.? I also have some suggested edits that you can consider: http://cr.openjdk.java.net/~mchung/valhalla/webrevs/nestmates-spec/ Mandy On 3/6/18 10:12 PM, David Holmes wrote: > The Nestmates CSR request: > > https://bugs.openjdk.java.net/browse/JDK-8197445 > > has been prepared by Dan Smith and myself. Before Proposing this CSR > request it needs to have Reviewers add themselves to it. > > (The first reviewer will need to edit the issue to enter their OpenJDK > user name in the "Reviewed by" field. Subsequent reviewers can simply > click on the "Reviewed by" field in the "People" section and add their > user name. > > The CSR contains links to all the updated specification documents, all > of which have been previously sent out for review/comment to the EG > (and observers). > > Thanks, > David -------------- next part -------------- An HTML attachment was scrubbed... URL: From daniel.smith at oracle.com Wed Mar 7 21:52:32 2018 From: daniel.smith at oracle.com (Dan Smith) Date: Wed, 7 Mar 2018 14:52:32 -0700 Subject: CONSTANT_Dynamic bootstrap signature restriction In-Reply-To: <1941514191.1222604.1520434126520.JavaMail.zimbra@u-pem.fr> References: <973DED2E-5274-40F3-B226-9F65EC832E34@oracle.com> <1992DC79-40B7-4EA7-9CC5-D5C060A73010@oracle.com> <0ad7e7c1-f5d9-2fff-dc4b-1741ab1ec32a@oracle.com> <1941514191.1222604.1520434126520.JavaMail.zimbra@u-pem.fr> Message-ID: <4640B132-3F93-476D-8529-A65BD3683F22@oracle.com> > On Mar 7, 2018, at 7:48 AM, Remi Forax wrote: > >> This might not pan out, and if so we can drop the error check and return to where we were. >> But it seems promising, and we don't want to get stuck in 11 making compatibility promises >> about the interpretation of things like 'bootstrap(Object... args)'. > > I think it's too late for that, once we had said that the bsm is called with methodhandle.invoke (or more recently invokeWithArguments), bootstrap(Object... args) is already a valid construct. The proposed rule detects a CONSTANT_Dynamic bootstrap of this form and rejects it, because the first parameter's type is not Lookup. This is an explicit check, not a side-effect of invokeWithArguments. In a plausible future (one that we want to make space for), rather than reporting an error, CONSTANT_Dynamic resolution will notice the lack of Lookup as a first parameter, and so pass an argument array to invokeWithArguments that doesn't contain the Lookup, name, or type. ?Dan From david.holmes at oracle.com Wed Mar 7 21:53:55 2018 From: david.holmes at oracle.com (David Holmes) Date: Thu, 8 Mar 2018 07:53:55 +1000 Subject: Nestmates: JEP 181 CSR request is ready for review In-Reply-To: References: Message-ID: Hi Karen, On 8/03/2018 5:47 AM, Karen Kinnear wrote: > David, > > Thank you so much for doing this. Very clear description. > > I marked this as ?Reviewed by" Thanks. > A minor review question: > > 1. Compatibility risk: > Would it make sense to add one more note: > Classes in the same package as an existing inner/outer class which took advantage of javac-generated > package private bridges to allow inner/outer class access to private members, will now receive an > IllegalAccessError. This is an intentional tightening of security for private member access. They won't get IllegalAccessError because their attempt to locate the bridge method will fail as it no longer exists. I think this is covered by the existing: "Recompilation with a new javac will produce different class files, leading to different reflection results (e.g., some bridge methods will no longer be generated). " But can be expanded if you think necessary. Thanks, David > thanks, > Karen > >> On Mar 7, 2018, at 1:12 AM, David Holmes wrote: >> >> The Nestmates CSR request: >> >> https://bugs.openjdk.java.net/browse/JDK-8197445 >> >> has been prepared by Dan Smith and myself. Before Proposing this CSR request it needs to have Reviewers add themselves to it. >> >> (The first reviewer will need to edit the issue to enter their OpenJDK user name in the "Reviewed by" field. Subsequent reviewers can simply click on the "Reviewed by" field in the "People" section and add their user name. >> >> The CSR contains links to all the updated specification documents, all of which have been previously sent out for review/comment to the EG (and observers). >> >> Thanks, >> David > From karen.kinnear at oracle.com Wed Mar 7 22:31:30 2018 From: karen.kinnear at oracle.com (Karen Kinnear) Date: Wed, 7 Mar 2018 17:31:30 -0500 Subject: Nestmates: JEP 181 CSR request is ready for review In-Reply-To: References: Message-ID: <938AA822-7014-4148-9193-B5A031E4777C@oracle.com> Actually - you are correct - the generated-trampoline name won?t exist - so you have already covered this more accurately. thanks, Karen > On Mar 7, 2018, at 4:53 PM, David Holmes wrote: > > Hi Karen, > > On 8/03/2018 5:47 AM, Karen Kinnear wrote: >> David, >> Thank you so much for doing this. Very clear description. >> I marked this as ?Reviewed by" > > Thanks. > >> A minor review question: >> 1. Compatibility risk: >> Would it make sense to add one more note: >> Classes in the same package as an existing inner/outer class which took advantage of javac-generated >> package private bridges to allow inner/outer class access to private members, will now receive an >> IllegalAccessError. This is an intentional tightening of security for private member access. > > They won't get IllegalAccessError because their attempt to locate the bridge method will fail as it no longer exists. I think this is covered by the existing: > > "Recompilation with a new javac will produce different class files, leading to different reflection results (e.g., some bridge methods will no longer be generated). " > > But can be expanded if you think necessary. > > Thanks, > David > >> thanks, >> Karen >>> On Mar 7, 2018, at 1:12 AM, David Holmes wrote: >>> >>> The Nestmates CSR request: >>> >>> https://bugs.openjdk.java.net/browse/JDK-8197445 >>> >>> has been prepared by Dan Smith and myself. Before Proposing this CSR request it needs to have Reviewers add themselves to it. >>> >>> (The first reviewer will need to edit the issue to enter their OpenJDK user name in the "Reviewed by" field. Subsequent reviewers can simply click on the "Reviewed by" field in the "People" section and add their user name. >>> >>> The CSR contains links to all the updated specification documents, all of which have been previously sent out for review/comment to the EG (and observers). >>> >>> Thanks, >>> David From forax at univ-mlv.fr Wed Mar 7 22:39:20 2018 From: forax at univ-mlv.fr (forax at univ-mlv.fr) Date: Wed, 7 Mar 2018 23:39:20 +0100 (CET) Subject: CONSTANT_Dynamic bootstrap signature restriction In-Reply-To: References: <973DED2E-5274-40F3-B226-9F65EC832E34@oracle.com> <1992DC79-40B7-4EA7-9CC5-D5C060A73010@oracle.com> <0ad7e7c1-f5d9-2fff-dc4b-1741ab1ec32a@oracle.com> <1941514191.1222604.1520434126520.JavaMail.zimbra@u-pem.fr> Message-ID: <503332467.1388664.1520462360776.JavaMail.zimbra@u-pem.fr> ----- Mail original ----- > De: "Brian Goetz" > ?: "Remi Forax" > Cc: "daniel smith" , "Daniel Heidinga" , "valhalla-spec-experts" > > Envoy?: Mercredi 7 Mars 2018 19:28:00 > Objet: Re: CONSTANT_Dynamic bootstrap signature restriction >> Daniel (S), Brian, >> i think your view on this subject is biased by the fact that you built that >> library. > > I can understand why you'd think that, but allow me to correct.? My view > is biased by the fact that I built the _first_ such library, and it was > pretty annoying, and I want to save future programmers from this > unnecessary annoyance.? And that we're working on language support that > virtually guarantees that others will want to write similar Java > libraries.? If this were just about compilers emitting bytecode, I > wouldn't care. Sure, javac support will help to have new users for condy but given the number people that have reviewed this API, it doesn't seem too popular, btw doing a proper review is on my todo list. Anyway, if you want to get ride of the first 3 parameters, you can trampoline, i.e having only one BSM that takes as first constant argument a method handle that construct the constants with fewer arguments and just call it. It's what i've done for the first version of cplisp [1]. Obviously it's not great in term of security so you also need to check that the given method handle had really been constructed from the lookup using lookup.revealDirect. > >> And i will re-use the argument than Brian use rightly about java.lang.invoke, >> not a lot of people will write BSMs, so modifying an already complex API call >> (callsite info * lazy loading of constants * conversion of bsm arguments * >> varargs) to take care of hiding potentially unused arguments only for few users >> does not worth the added complexity. > > I am saying that I imagine a future where the number of people writing > BSMs for condy is at least 100x bigger than it has been historically. > Again, if I thought this was just about me and you and Charlie, I > wouldn't care.? But I don't think that's the case here. I can imagine a lot of things, but we can also wait and see if the API becomes popular now that we are in a 6 month cadence. R?mi [1] https://github.com/forax/cplisp From forax at univ-mlv.fr Wed Mar 7 22:51:46 2018 From: forax at univ-mlv.fr (forax at univ-mlv.fr) Date: Wed, 7 Mar 2018 23:51:46 +0100 (CET) Subject: CONSTANT_Dynamic bootstrap signature restriction In-Reply-To: <4640B132-3F93-476D-8529-A65BD3683F22@oracle.com> References: <973DED2E-5274-40F3-B226-9F65EC832E34@oracle.com> <1992DC79-40B7-4EA7-9CC5-D5C060A73010@oracle.com> <0ad7e7c1-f5d9-2fff-dc4b-1741ab1ec32a@oracle.com> <1941514191.1222604.1520434126520.JavaMail.zimbra@u-pem.fr> <4640B132-3F93-476D-8529-A65BD3683F22@oracle.com> Message-ID: <2005786316.1391125.1520463106101.JavaMail.zimbra@u-pem.fr> ----- Mail original ----- > De: "daniel smith" > ?: "Remi Forax" > Cc: "valhalla-spec-experts" > Envoy?: Mercredi 7 Mars 2018 22:52:32 > Objet: Re: CONSTANT_Dynamic bootstrap signature restriction >> On Mar 7, 2018, at 7:48 AM, Remi Forax wrote: >> >>> This might not pan out, and if so we can drop the error check and return to >>> where we were. >>> But it seems promising, and we don't want to get stuck in 11 making >>> compatibility promises >>> about the interpretation of things like 'bootstrap(Object... args)'. >> >> I think it's too late for that, once we had said that the bsm is called with >> methodhandle.invoke (or more recently invokeWithArguments), bootstrap(Object... >> args) is already a valid construct. > > The proposed rule detects a CONSTANT_Dynamic bootstrap of this form and rejects > it, because the first parameter's type is not Lookup. This is an explicit > check, not a side-effect of invokeWithArguments. My point is that you can do that for Condy but not for Indy because Indy is already specified in term of invokeWithArguments. And i think everybody in the EG that has to maintain a VM implementation will agree with me that it's better to have Indy and Condy semantics to be aligned. > > In a plausible future (one that we want to make space for), rather than > reporting an error, CONSTANT_Dynamic resolution will notice the lack of Lookup > as a first parameter, and so pass an argument array to invokeWithArguments that > doesn't contain the Lookup, name, or type. If the first arguments of a BSM is an Object and not a Lookup, it's not an error, unlike a classical Java call, a bsm call is linked dynamically so the signature of a bsm do not have to exactly match with its calling arguments. > > ?Dan R?mi From david.holmes at oracle.com Thu Mar 8 07:28:57 2018 From: david.holmes at oracle.com (David Holmes) Date: Thu, 8 Mar 2018 17:28:57 +1000 Subject: Nestmates: JEP 181 CSR request is ready for review In-Reply-To: References: Message-ID: <8f0f0a67-15e9-c44d-7d33-a169de422e2a@oracle.com> Hi Mandy, On 8/03/2018 6:12 AM, mandy chung wrote: > Hi David, > > I'm reviewing the core reflection and j.l.invoke spec change. Thanks for looking at this. > I think Class::getNestHost and Class::getNestMembers should do a security > permission check as performed in other method e.g. getEnclosingClass. > > ???? * @throws SecurityException > ???? *???????? If a security manager, s, is present and > ???? *???????? the caller's class loader is not the same as or an > ???? *???????? ancestor of the class loader for the current class and > ???? *???????? invocation of {@link SecurityManager#checkPackageAccess > ???? *???????? s.checkPackageAccess()} denies access to the package > ???? *???????? of this class > ???? * That's an interesting point. Should they also be @CallerSensitive? It may be we have to perform the SM check, but throwing SecurityException is somewhat contrary to the "no exceptions" approach of getNestHost(). I filed an issue to track this: https://bugs.openjdk.java.net/browse/JDK-8199309 > I suggest to make @apiNote in Class::getNestHost as just part of javadoc. > It can define a section like "Nest Membership" that can be referenced My understanding is that @apiNote et al were introduced to more clearly distinguish between the actual specification part of the Javadoc and other non-normative text. As this is non-normative then @apiNote seems most appropriate. I presume we can still add a tag to allow cross-referencing from inside Class itself. > by Lookup class spec. Cross-referencing internal text fragments across distinct javadoc is something I thought was not done. ?? > I also have some suggested edits that you can > consider: > > http://cr.openjdk.java.net/~mchung/valhalla/webrevs/nestmates-spec/ Some of these are okay but this part: * The source language compiler is responsible for deciding which classes * and interfaces are nestmates. For example, the {@code javac} compiler is quite significant and should not be lost. A source compiler is free to chose not to use the new attributes (and of course not benefit from the new access control rules but continue to rely on access-bridges.) So the user of the API has to be aware of this. And in MethodHandles I know there is a dislike of versioning text "Since JDK 11 ..." (though I see this as no different to using @since!), but again this new behaviour may or may not be present depending on the version of the classfiles and the compiler used to create them, so it is critical to me that this is very clearly stated. I suppose this could be re-stated in the form: "If the relationship between nested types is expressed directly through the {@code NestHost} and {@code NestMembers} attributes (see the Java Virtual Machine Specification, sections 4.7.28 and 4.7.29), then the associated {@code Lookup} object provides direct access to the lookup class and all of its nestmates. Otherwise, access between nested classes is obtained by the Java compiler creating a wrapper method to ..." Thanks, David > Mandy > > On 3/6/18 10:12 PM, David Holmes wrote: >> The Nestmates CSR request: >> >> https://bugs.openjdk.java.net/browse/JDK-8197445 >> >> has been prepared by Dan Smith and myself. Before Proposing this CSR >> request it needs to have Reviewers add themselves to it. >> >> (The first reviewer will need to edit the issue to enter their OpenJDK >> user name in the "Reviewed by" field. Subsequent reviewers can simply >> click on the "Reviewed by" field in the "People" section and add their >> user name. >> >> The CSR contains links to all the updated specification documents, all >> of which have been previously sent out for review/comment to the EG >> (and observers). >> >> Thanks, >> David > From daniel.smith at oracle.com Thu Mar 8 18:17:00 2018 From: daniel.smith at oracle.com (Dan Smith) Date: Thu, 8 Mar 2018 11:17:00 -0700 Subject: CONSTANT_Dynamic bootstrap signature restriction In-Reply-To: <2005786316.1391125.1520463106101.JavaMail.zimbra@u-pem.fr> References: <973DED2E-5274-40F3-B226-9F65EC832E34@oracle.com> <1992DC79-40B7-4EA7-9CC5-D5C060A73010@oracle.com> <0ad7e7c1-f5d9-2fff-dc4b-1741ab1ec32a@oracle.com> <1941514191.1222604.1520434126520.JavaMail.zimbra@u-pem.fr> <4640B132-3F93-476D-8529-A65BD3683F22@oracle.com> <2005786316.1391125.1520463106101.JavaMail.zimbra@u-pem.fr> Message-ID: > On Mar 7, 2018, at 3:51 PM, forax at univ-mlv.fr wrote: > > ----- Mail original ----- >> De: "daniel smith" >> ?: "Remi Forax" >> Cc: "valhalla-spec-experts" >> Envoy?: Mercredi 7 Mars 2018 22:52:32 >> Objet: Re: CONSTANT_Dynamic bootstrap signature restriction > >>> On Mar 7, 2018, at 7:48 AM, Remi Forax wrote: >>> >>>> This might not pan out, and if so we can drop the error check and return to >>>> where we were. >>>> But it seems promising, and we don't want to get stuck in 11 making >>>> compatibility promises >>>> about the interpretation of things like 'bootstrap(Object... args)'. >>> >>> I think it's too late for that, once we had said that the bsm is called with >>> methodhandle.invoke (or more recently invokeWithArguments), bootstrap(Object... >>> args) is already a valid construct. >> >> The proposed rule detects a CONSTANT_Dynamic bootstrap of this form and rejects >> it, because the first parameter's type is not Lookup. This is an explicit >> check, not a side-effect of invokeWithArguments. > > My point is that you can do that for Condy but not for Indy because Indy is already specified in term of invokeWithArguments. > And i think everybody in the EG that has to maintain a VM implementation will agree with me that it's better to have Indy and Condy semantics to be aligned. You have correctly identified the trade-off: ease of use for condy (in the future, if we decide to pursue it) vs. consistency with indy. Our claim is that it is *possible* that the inconsistency will be worth it. If not, we can drop the restriction and make things consistent again. FWIW, another goal is to move most of this logic into an API, so that it will no longer be a matter for VM implementations (and specifications!) to have to worry about. ?Dan -------------- next part -------------- An HTML attachment was scrubbed... URL: From mandy.chung at oracle.com Thu Mar 8 19:33:10 2018 From: mandy.chung at oracle.com (mandy chung) Date: Thu, 8 Mar 2018 11:33:10 -0800 Subject: Nestmates: JEP 181 CSR request is ready for review In-Reply-To: <8f0f0a67-15e9-c44d-7d33-a169de422e2a@oracle.com> References: <8f0f0a67-15e9-c44d-7d33-a169de422e2a@oracle.com> Message-ID: On 3/7/18 11:28 PM, David Holmes wrote: > > That's an interesting point. Should they also be @CallerSensitive? > Yes. I hope SM::checkPackageAccess check will be removed some day as we now have strong encapsulation. The security team has considered this and requires further investigation. > It may be we have to perform the SM check, but throwing > SecurityException is somewhat contrary to the "no exceptions" approach > of getNestHost(). > The SecurityException will only be thrown when security manager is installed and permission denies.?? Users are responsible to configure the security policy to grant proper permission. > I filed an issue to track this: > > https://bugs.openjdk.java.net/browse/JDK-8199309 > >> I suggest to make @apiNote in Class::getNestHost as just part of >> javadoc. >> It can define a section like "Nest Membership" that can be referenced > > My understanding is that @apiNote et al were introduced to more > clearly distinguish between the actual specification part of the > Javadoc and other non-normative text. As this is non-normative then > @apiNote seems most appropriate. I presume we can still add a tag to > allow cross-referencing from inside Class itself. The definition of a nest is a specification that has no issue to include in the javadoc. > >> by Lookup class spec. > > Cross-referencing internal text fragments across distinct javadoc is > something I thought was not done. ?? > >> I also have some suggested edits that you can >> consider: >> >> http://cr.openjdk.java.net/~mchung/valhalla/webrevs/nestmates-spec/ > > Some of these are okay but this part: > > ? * The source language compiler is responsible for deciding which > classes > ? * and interfaces are nestmates. For example, the {@code javac} compiler > > is quite significant and should not be lost. A source compiler is free > to chose not to use the new attributes (and of course not benefit from > the new access control rules but continue to rely on access-bridges.) > So the user of the API has to be aware of this. > This can be retained in @apiNote. > And in MethodHandles I know there is a dislike of versioning text > "Since JDK 11 ..." (though I see this as no different to using > @since!), but again this new behaviour may or may not be present > depending on the version of the classfiles and the compiler used to > create them, so it is critical to me that this is very clearly stated. > I suppose this could be re-stated in the form: > > "If the relationship between nested types is expressed directly > through the {@code NestHost} and {@code NestMembers} attributes (see > the Java Virtual Machine Specification, sections 4.7.28 and 4.7.29), > then the associated {@code Lookup} object provides direct access to > the lookup class and all of its nestmates. Otherwise, access between > nested classes is obtained by the Java compiler creating a wrapper > method to ..." > This is fine too. ? I still think a @linkplain to Class#nestmates would be useful. Mandy > Thanks, > David > >> Mandy >> >> On 3/6/18 10:12 PM, David Holmes wrote: >>> The Nestmates CSR request: >>> >>> https://bugs.openjdk.java.net/browse/JDK-8197445 >>> >>> has been prepared by Dan Smith and myself. Before Proposing this CSR >>> request it needs to have Reviewers add themselves to it. >>> >>> (The first reviewer will need to edit the issue to enter their >>> OpenJDK user name in the "Reviewed by" field. Subsequent reviewers >>> can simply click on the "Reviewed by" field in the "People" section >>> and add their user name. >>> >>> The CSR contains links to all the updated specification documents, >>> all of which have been previously sent out for review/comment to the >>> EG (and observers). >>> >>> Thanks, >>> David >> -------------- next part -------------- An HTML attachment was scrubbed... URL: From david.holmes at oracle.com Thu Mar 8 20:45:15 2018 From: david.holmes at oracle.com (David Holmes) Date: Fri, 9 Mar 2018 06:45:15 +1000 Subject: Nestmates: JEP 181 CSR request is ready for review In-Reply-To: References: <8f0f0a67-15e9-c44d-7d33-a169de422e2a@oracle.com> Message-ID: Thanks Mandy. We'll take the javadoc editing discussion off-list and I'll come back to the EG when any changes are made. David On 9/03/2018 5:33 AM, mandy chung wrote: > > > On 3/7/18 11:28 PM, David Holmes wrote: >> >> That's an interesting point. Should they also be @CallerSensitive? >> > > Yes. > > I hope SM::checkPackageAccess check will be removed some day as we now > have strong encapsulation. The security team has considered this and > requires further investigation. > >> It may be we have to perform the SM check, but throwing >> SecurityException is somewhat contrary to the "no exceptions" approach >> of getNestHost(). >> > > The SecurityException will only be thrown when security manager is > installed and permission denies.?? Users are responsible to configure > the security policy to grant proper permission. > >> I filed an issue to track this: >> >> https://bugs.openjdk.java.net/browse/JDK-8199309 >> > >>> I suggest to make @apiNote in Class::getNestHost as just part of >>> javadoc. >>> It can define a section like "Nest Membership" that can be referenced >> >> My understanding is that @apiNote et al were introduced to more >> clearly distinguish between the actual specification part of the >> Javadoc and other non-normative text. As this is non-normative then >> @apiNote seems most appropriate. I presume we can still add a tag to >> allow cross-referencing from inside Class itself. > > The definition of a nest is a specification that has no issue to include > in the javadoc. >> >>> by Lookup class spec. >> >> Cross-referencing internal text fragments across distinct javadoc is >> something I thought was not done. ?? >> > > > >>> I also have some suggested edits that you can >>> consider: >>> >>> http://cr.openjdk.java.net/~mchung/valhalla/webrevs/nestmates-spec/ >> >> Some of these are okay but this part: >> >> ? * The source language compiler is responsible for deciding which >> classes >> ? * and interfaces are nestmates. For example, the {@code javac} compiler >> >> is quite significant and should not be lost. A source compiler is free >> to chose not to use the new attributes (and of course not benefit from >> the new access control rules but continue to rely on access-bridges.) >> So the user of the API has to be aware of this. >> > > This can be retained in @apiNote. > >> And in MethodHandles I know there is a dislike of versioning text >> "Since JDK 11 ..." (though I see this as no different to using >> @since!), but again this new behaviour may or may not be present >> depending on the version of the classfiles and the compiler used to >> create them, so it is critical to me that this is very clearly stated. >> I suppose this could be re-stated in the form: >> >> "If the relationship between nested types is expressed directly >> through the {@code NestHost} and {@code NestMembers} attributes (see >> the Java Virtual Machine Specification, sections 4.7.28 and 4.7.29), >> then the associated {@code Lookup} object provides direct access to >> the lookup class and all of its nestmates. Otherwise, access between >> nested classes is obtained by the Java compiler creating a wrapper >> method to ..." >> > > This is fine too. ? I still think a @linkplain to Class#nestmates would > be useful. > > Mandy > >> Thanks, >> David >> >>> Mandy >>> >>> On 3/6/18 10:12 PM, David Holmes wrote: >>>> The Nestmates CSR request: >>>> >>>> https://bugs.openjdk.java.net/browse/JDK-8197445 >>>> >>>> has been prepared by Dan Smith and myself. Before Proposing this CSR >>>> request it needs to have Reviewers add themselves to it. >>>> >>>> (The first reviewer will need to edit the issue to enter their >>>> OpenJDK user name in the "Reviewed by" field. Subsequent reviewers >>>> can simply click on the "Reviewed by" field in the "People" section >>>> and add their user name. >>>> >>>> The CSR contains links to all the updated specification documents, >>>> all of which have been previously sent out for review/comment to the >>>> EG (and observers). >>>> >>>> Thanks, >>>> David >>> > From brian.goetz at oracle.com Thu Mar 8 22:15:32 2018 From: brian.goetz at oracle.com (Brian Goetz) Date: Thu, 8 Mar 2018 17:15:32 -0500 Subject: CONSTANT_Dynamic bootstrap signature restriction In-Reply-To: <503332467.1388664.1520462360776.JavaMail.zimbra@u-pem.fr> References: <973DED2E-5274-40F3-B226-9F65EC832E34@oracle.com> <1992DC79-40B7-4EA7-9CC5-D5C060A73010@oracle.com> <0ad7e7c1-f5d9-2fff-dc4b-1741ab1ec32a@oracle.com> <1941514191.1222604.1520434126520.JavaMail.zimbra@u-pem.fr> <503332467.1388664.1520462360776.JavaMail.zimbra@u-pem.fr> Message-ID: <0ef93138-a4ce-20a3-51f0-c17c4418b74c@oracle.com> I'm fine putting in Dan's restriction and buying the option to do it or not.? But, if we don't put in the restriction, then we can never do it.? Not fine with that. > My point is that you can do that for Condy but not for Indy because Indy is already specified in term of invokeWithArguments. > And i think everybody in the EG that has to maintain a VM implementation will agree with me that it's better to have Indy and Condy semantics to be aligned. I don't actually agree to that.? Sure, all things being equal, gratuitous misalignment is unfortunate.? But, we've learned a lot since indy, and I think that Condy will be used 100x more than indy, and (at least in static languages like Java), the vast majority of indy (any that return CCS) will become condy.? So given the choice between "follow in the footsteps of indy's limitation", and "make condy even better", I choose for the latter, and the inconsistency is a small price to pay. Further argument: I think metadata-less condy will be very frequent.? But of the indy's that can't become condy (those with mutable call sites), I think few of them can be metadata-less.? So the asymmetry makes condy much better and doesn't make indy much worse. On 3/7/2018 5:39 PM, forax at univ-mlv.fr wrote: > ----- Mail original ----- >> De: "Brian Goetz" >> ?: "Remi Forax" >> Cc: "daniel smith" , "Daniel Heidinga" , "valhalla-spec-experts" >> >> Envoy?: Mercredi 7 Mars 2018 19:28:00 >> Objet: Re: CONSTANT_Dynamic bootstrap signature restriction >>> Daniel (S), Brian, >>> i think your view on this subject is biased by the fact that you built that >>> library. >> I can understand why you'd think that, but allow me to correct.? My view >> is biased by the fact that I built the _first_ such library, and it was >> pretty annoying, and I want to save future programmers from this >> unnecessary annoyance.? And that we're working on language support that >> virtually guarantees that others will want to write similar Java >> libraries.? If this were just about compilers emitting bytecode, I >> wouldn't care. > Sure, javac support will help to have new users for condy but given the number people that have reviewed this API, it doesn't seem too popular, > btw doing a proper review is on my todo list. > > Anyway, if you want to get ride of the first 3 parameters, you can trampoline, i.e having only one BSM that takes as first constant argument a method handle that construct the constants with fewer arguments and just call it. It's what i've done for the first version of cplisp [1]. Obviously it's not great in term of security so you also need to check that the given method handle had really been constructed from the lookup using lookup.revealDirect. > >>> And i will re-use the argument than Brian use rightly about java.lang.invoke, >>> not a lot of people will write BSMs, so modifying an already complex API call >>> (callsite info * lazy loading of constants * conversion of bsm arguments * >>> varargs) to take care of hiding potentially unused arguments only for few users >>> does not worth the added complexity. >> I am saying that I imagine a future where the number of people writing >> BSMs for condy is at least 100x bigger than it has been historically. >> Again, if I thought this was just about me and you and Charlie, I >> wouldn't care.? But I don't think that's the case here. > I can imagine a lot of things, but we can also wait and see if the API becomes popular now that we are in a 6 month cadence. > > R?mi > > [1] https://github.com/forax/cplisp From karen.kinnear at oracle.com Fri Mar 9 22:13:54 2018 From: karen.kinnear at oracle.com (Karen Kinnear) Date: Fri, 9 Mar 2018 17:13:54 -0500 Subject: Valhalla EG notes Feb 28, 2018 Message-ID: <255254DA-45E2-42BF-AC26-8EFBA87E7640@oracle.com> Attendees: Remi, John, Dan H, Lois, Tobi, Frederic, Karen Corrections always welcome. Condy, Nestmates - merging Dan?s early JVMS/JLS drafts into the next full JVMS/JLS. We will send out a link when they get posted so we can all review the merged changes. I. Value Types 1. Review of nullability for value fields: Nullability for fields is declared by the container via ACC_FLATTENABLE field modifier in the classfile. This only applies to value type fields.This implies non-nullable. If ACC_FLATTENABLE then: must preload before completing loading of the class must initialize to the default value attempts to store to the field (publish) throws NullPointerException Implementation determines if the field is actually flattened, but the semantics remain unchanged. John: this is a JVMS, not a java language specification. Java can choose its own default as well as any language syntax later. Frederic: rationale is the compatibility story. Allows existing value-based-classes like Optional to migrate to become value types and allow classfiles that declare Optional fields, and clients that access those fields to continue to work unchanged, including the ability to store/retrieve a null. Note: arguments, local variables can contain a null for a value type, it is only when publishing that an NPE is thrown. John: not calling this non-nullable from a language feature perspective. Might be something more like ?probable flattening?. Remi: why preload? John: If we defer loading we might get circularity errors which should prevent the container from loading 2. Nullability for arrays Based on emails this week between Mr Simms, Remi, John on valhalla-dev at openjdk.java.net, here is a summary of a new proposal: Value type arrays are always flattenable, and therefore not nullable If the end user wants non-flattenable/nullable they can use Object[] or Interface[] or maybe a future reflective API if needed that creates a reference array - but for now let us assume that value type arrays are always flattenable, prototype that and then we can assess what the cost might be if we need dynamic checking. As with fields, implementation determines if the component is actually flattened. bytecode implications: aaload - returns default from default initialized value type component aastore - throws NPE if attempt to store null. Must store default value for component anewarray/multianewarray - if the component is a value type, create a value type array (note: rough draft JVMS needs updating) Remi: what about compatibility? if you read an array that is empty today, you get null if you read a flattened array, you get a default value John: with arrays we do not need to do any preloading so no benefits to not always flattenable believe limited use cases for non-flattenable arrays solving the JVM part - not the user model or language Remi: concern Optional[] - will no longer see nulls John: Optional is not supposed to be seen in the heap - with generics, there are no Optional[] that are reified - so erasure saves us Remi: Kotlin, ??, Scala - reify John: languages can make their own compatibility decisions Remi: can buy argument John: let?s prototype this and see Dan H: sanity checking that the default value for arrays is not user supplied - to avoid cost of walking & storing YES Dan H: assuming all value[] flattenable Karen: yes - not nullable, no guarantee flattened Remi: want to know if actually flattened - e.g. for performance John: tools that give you the information of what is in the heap and the shape of the object Remi: tool was deprecated (jhat) - want to know at runtime Karen: serviceability issue John: or reflection Karen: no control over this Frederic: might change by platform or command-line args 3. Atomics Tobi: Concern if write a value type to a flattenable field in a container want to ensure atomicity of field or array component update need clear rules of what to expect e.g. doubles and longs today can tear John: meeting with Doug Lea - guidance: Do not worry about flattening by default - do not lose the performance model in general need explicit non-tearing, e.g. for security sensitive Need to explore possible approaches: e.g. declare a class as always atomic e.g. atomic up to hw atomic support, or use seqlocks, or don?t flatten for performance Tobi/Dan H: JVMS - we need to document that value types are tearable by default (ed. note: we need to update rough draft JVMS - yes!) John: possibilities: volatile field or entire class as volatile Tobi: value based class today will not tear -> migrate to value class: changes behavior (ed. note: for arrays - yes, for fields no - default is not flattenable so existing classes unchanged) John: explore: if e.g. the class is ACC_VOLATILE, perhaps non-tearability for fields together, not for each field? - note: only on heap Karen: need to research Remi: only for value types? John: yes - references are already non-tearable Note: prototyping for atomicity - seqlocks or indirection - seqlocks slow -> ask Intel folks for help 4. Creation: scope of withfield Remi: from a vm perspective - understand why not a vnew bytecode rest - language level discussion Karen: default: anywhere withfield: restricted to nest Remi: not ok with restriction on withfield encapsulation by modifier not by opcodes John: invoke special - some modes restricted John: wants to restrict ?new? in future alien thing having a public field, this is as if withfield checks a different public bit Remi: accessors are created for this John: classfile - all value type fields are final, none are writeable outside the nest Remi: use case: change inner class to be a top-level class - can?t use withfield John: ?Reconstructors? with: create a new object, want withfield inside the nest and checked access points outside nest Remi: other languages do not want to mix opcodes and access checks Dan H: do you need access to withfield or do you need factory methods? Karen: want factory - e.g. validate interdependencies between fields Remi: serialization - in jvm, not in java, to create a value type from outside data John: serialization has to overcome final in a field, e.g. SetAccessible today - unless figure out a better way - why not call a Reconstructor? Remi: what if constructor is private? John: serialization needs to call private constructors anyway Remi: value types will have constructors John: yes, but not unless maybe static which does not return void? Karen: verifier would prefer a different name John: bikeshed - but maybe different special name Remi: default bytecode Frederic: return is usable always Remi: ValueRecord will need Object Classes: final fields are written by constructor Value classes: final fields are written by anyone in the nest naming: canonical universal constructor for serialization John: maybe ? longterm control of use of new bytecode only instantiable via factory methods vm old code - compatibility future: new only in factory methods. > security, still need e.g. for Supers naming convention benefits stronger than just Records or serialization uses Dan H: likes the move away from new/dup/ concern: legacy corpus - long-term play Karen: like security and more shareable code - e.g. for generics - if common naming/able to call a factory John: language decision - maybe use C++ notation, drop the ?new?, e.g. (typename)arg , ? Remi: value-based-class change to value class - language level goal? e.g. new optional? John: how compatible? Issue a warning? Dan: Why would vm offer a canonical name? John: today has special rules - no special rules for verifier - naming - ensure not in valid namespace for java programmer Dan H: new/dup/ in nest in future? John: yes John: yes. has signature with void return today, maybe if use with non-void return? Remi: if retrofit void as a value type -> then not distinguishable John: maybe overloaded with args. must always be static From john.r.rose at oracle.com Sat Mar 10 21:01:10 2018 From: john.r.rose at oracle.com (John Rose) Date: Sat, 10 Mar 2018 13:01:10 -0800 Subject: Valhalla EG notes Feb 28, 2018 In-Reply-To: <255254DA-45E2-42BF-AC26-8EFBA87E7640@oracle.com> References: <255254DA-45E2-42BF-AC26-8EFBA87E7640@oracle.com> Message-ID: <6C4608FC-4ADF-4A48-93AA-2551E9268A9E@oracle.com> Excellent notes as always. (Impressive how you collect them and also take a full part in the conversation.) On Mar 9, 2018, at 2:13 PM, Karen Kinnear wrote: > > Attendees: Remi, John, Dan H, Lois, Tobi, Frederic, Karen > > Corrections always welcome. > > John: this is a JVMS, not a java language specification. Java can choose its own default as well as any language syntax later. Footnote: our current intention, at the language level, is to sweep as much of the null corner casing under the rug as possible. One specific is that I hope the "ACC_FLATTENABLE" bit will be placed on *all* fields that are seen at compile-time to be value types. The two alternatives I hope to avoid are (a) making ACC_FLATTENABLE explicit at the source level requiring explicit opt-in to a flat container, and (b) default ACC_FLATTENABLE with an opt-out that says "make this nullable". One reason: I don't want nullable value types to be supported as a first-class language construct; they would be misused. Another reason: Conversations like "A: this gives me no performance benefit, you are such losers; B: did you remember to set your nullability correctly? A: what's nullability?" And, under the "field == element" heuristic, similar set of considerations for whether to supply value arrays that are only flattenable, only nullable, or sometimes both (and how to set the default in that case). Desired positions are (a) flat is the default, and (b) nullable may be available as a workaround if you try hard, but not as a first-class language feature. > Frederic: rationale is the compatibility story. Allows existing value-based-classes like Optional to migrate to become value types and allow classfiles that declare Optional fields, and clients that access those fields to continue to work unchanged, including the ability to store/retrieve a null. > > Note: arguments, local variables can contain a null for a value type, it is only when publishing that an NPE is thrown. > > John: not calling this non-nullable from a language feature perspective. Might be something more like ?probable flattening?. > > Remi: why preload? > John: If we defer loading we might get circularity errors which should prevent the container from loading Preloading, of field types, is required in order to discover the layout of a field type. This isn't necessary for object types since those are always reached by pointers, and all pointers are laid out the same. The need for preloading a field type is only necessary if the field type is a value type *and* the containing object is going to (attempt to) flatten the field. The discussion I recall is that Remi wasn't asking why we preload, but rather why *not* preload more often, in order to more correctly decide in favor of flattening. In particular, we preload superclasses (again for layout reasons!) and interfaces (for layout reasons, in the v-tables), so why not just preload every field type, on the chance that it *might* be value type, and then we can DTRT. I wish we could! IIRC Karen went through this exercise and noticed that various circular loading dependencies made this impossible. Loading all of your supers is possible because the subtyping graph is acyclic, so you can use a lazy loading algorithm to get everything straight. (With lots of hairy infra to manage concurrency and cycle detection. See ClassCircularityError.) Doing this for fields doesn't just require *more* hairy infra, it is *impossible* because field incorporation is a cyclic graph, even for very simple programs. Perhaps I misunderstood Remi's question. Remi has a very clever proposal for the compiler to emit an extra attribute in the classfile which says "I assume the following types are value types". This would allow limited preloading, and we could exclude cycles in this graph. (The reason is that you can't have value A including value B directly or indirectly; you logically need an object somewhere in the graph, and that breaks any cycle in Remi's attribute relations.) The use of the modifier bit ACC_FLATTENABLE, on fields only rather than general value types, is a simplification and limitation of Remi's clever proposal, which we hope will be sufficient as well as easier to specify and implement. > ... > Remi: what about compatibility? > if you read an array that is empty today, you get null > if you read a flattened array, you get a default value > > John: with arrays we do not need to do any preloading so no benefits to not always flattenable > believe limited use cases for non-flattenable arrays (Remi's clever proposal of a "values committee" in every classfile, which determines the potential flatness of fields, may lead to annoying questions like, "does the committee also determine the flatness of arrays created by that class?" and "does the committee also determine the null-permissiveness of instruction xyz?" As well as dealing with cases when the committees in different classfiles make different decisions.) > solving the JVM part - not the user model or language > > Remi: concern Optional[] - will no longer see nulls > John: Optional is not supposed to be seen in the heap > - with generics, there are no Optional[] that are reified - so erasure saves us > Remi: Kotlin, ??, Scala - reify > John: languages can make their own compatibility decisions > Remi: can buy argument > John: let?s prototype this and see One option for other languages, that I think will be workable in many cases, is to use erasure to implement the occasional case of a nullable use of a value type. I.e., erase the value type to its bound, and insert casts. (Make user null checks happen before any cast, since the cast will probably NPE on nulls.) So erase the null-permissive type `ComplexDouble?` to JVM Object and surround with casts of `ComplexDouble!` as needed, where the JVM type of `ComplexDouble!` is `ComplexDouble` Another more complex option is to wrap. Where erasure goes upward, wrapping goes outward. Implement `ComplexDouble?` with an auxiliary value type with a single nullable field (lacking the ACC_FLATTENABLE bit). Or make an object type which boxes. > ... > John: language decision - maybe use C++ notation, drop the ?new?, e.g. (typename)arg , ? "Drop the new" is TypeName(arg), as in var i = ComplexDouble(0, 1); That's the consensus. Despite the fact that it's ambiguous, since there might be a method nearby called ComplexDouble. Since this is unlikely we can add a rule which resolves the ambiguity in a compatible way (take the method if there is one) and be done. In such cases you also need a way to opt into the non-legacy behavior. That would involve an explicit qualifier on the class name, including maybe something new like ComplexDouble.ComplexDouble(0, 1), just to handle the vanishingly unlikely second-order corner cases on the corner cases. (Doug Lea's guidance was, "just do it; don't worry about the corner cases".) > ... > Dan: Why would vm offer a canonical name? > > John: today has special rules > - no special rules for verifier > - naming - ensure not in valid namespace for java programmer > > Dan H: new/dup/ in nest in future? John: yes > John: yes. has signature with void return today, maybe if use with non-void return? > Remi: if retrofit void as a value type -> then not distinguishable > John: maybe overloaded with args. must always be static (I'm going to send a separate note about this.) ? John -------------- next part -------------- An HTML attachment was scrubbed... URL: From john.r.rose at oracle.com Sat Mar 10 21:16:21 2018 From: john.r.rose at oracle.com (John Rose) Date: Sat, 10 Mar 2018 13:16:21 -0800 Subject: vs. vs. $make, named [de/re]constructors In-Reply-To: <6C4608FC-4ADF-4A48-93AA-2551E9268A9E@oracle.com> References: <255254DA-45E2-42BF-AC26-8EFBA87E7640@oracle.com> <6C4608FC-4ADF-4A48-93AA-2551E9268A9E@oracle.com> Message-ID: On Mar 10, 2018, at 1:01 PM, John Rose wrote: > (I'm going to send a separate note about this.) We discussed one future option to make the JVM specially aware of the way it is aware of , and then restrict the new/dup/ dance to *only* occur inside of in the same nest. If this is the only reason to coin a new magic name , it might not be enough motivation. But there might be other reasons. Another reason for a magic name is to unambiguously link the source construct DoubleComplex(a,b) to a factory method. The JVM does *not* replicate the class base-name as the factory name, and I'd like to avoid that in the future too; I think it's just an artifact of Java's C++ heritage, and nothing to do with VM-level requirements. Hence is the VM-level name where the type name occurs in the source code. So for factories we also need a canonical name for a value class's "principal factory". It could be $make or or some other bikeshed color. I slightly prefer because I think we *will* want to hook some structural constraints on it, and that's easier to swallow of the name is *really* magic, rather than "look he's got a dollar sign on him!". Another way is to allow the translation strategy and/or user to choose the factory name, and for the JVM to define an ACC_FACTORY bit to do the jobs that would do. We'd still want, IMO, to fold DoubleComplex down to something like $make, but with the ACC_FACTORY bit. Either ACC_FACTORY or scales out to other uses besides value type factories. It allows named factories on any kind of type. If we do a translation rule, for values, where DoubleComplex(a,b) is a call to DoubleComplex.$make(a,b), we can also take a later option to have List(a,b) be a call to List.of(a,b), where the ACC_FACTORY bit on List.of gates the decision. Or we would add List. which calls List.of, for the same effect. (I happen to find List(a,b) attractive, though surely opinions will vary widely. Doubtless some people find "new" reassuring, and it was very reassuring in the long ago days when folks didn't trust GC technology and wanted to keep a sharp eye on allocation sites. But the days are long gone of "new" being part of a crisp, simple performance model.) A decision to use $make/ACC_FACTORY instead of allows named factories too: DoubleComplex.imag(x), etc. That seems to be a vote in favor of $make not , or perhaps an argument to have both, one for structural constraints and one for naming of principal factories. We are discovering as part of the Amber project that constructors often occur paired with deconstructors. Principal constructors (or for values factories) are paired with principal deconstructors, which unpack an object in exactly the reverse order in which it was packed by its principal constructor. Name factories want to be paired, also, with named deconstructors. (Anti-factories? Co-factories? Salvage yards?) This leads to the possibility that, if a factory has structural constraints, then maybe a deconstructor has coordinated constraints. I'm just speculating here; I don't see a concrete example yet, except perhaps the treatment of final fields. (See below.) This leads me to the following tentative results, which seem "OK for today" but could change: - The new/dup/ dance could be constrained to nests, but there's no tighter constraint (like factories only) that seems useful. - No need seen, yet, for ACC_FACTORY. - Java translation strategies need a tactic for naming principal factories. And for naming deconstructors paired with constructors or factories. There isn't a firm need for the JVM to help with this but doing so would be unsurprising, given . There is a similar line of consideration for handling the initialization *and reinitialization* of final fields, in reconstructors *and reconstructors*. Marking reconstructors (like withers) *might* require an ACC_* bit to relieve structural constraints that relate to final fields, and currently allow enhanced access inside of but only there. Named [re]constructors might need similar access, leading to either an ACC_CONSTRUCTOR bit or else a relaxation of some capabilities to the whole nest. So another "OK for today" conclusion might be: - Consider marking some methods as ACC_RECONSTRUCTOR and allowing final updates in those methods. Use this marker on reconstructors, in place of some extension of the code shapes, which are already overburdened. - Or, consider relaxing rules for update of final fields to the whole nest. (I know we just fixed a security bug in that space, but still look at it.) ? John From john.r.rose at oracle.com Sun Mar 11 02:56:29 2018 From: john.r.rose at oracle.com (John Rose) Date: Sat, 10 Mar 2018 18:56:29 -0800 Subject: Iterators vs. Cursors: A Case Study in Objects vs. Values Message-ID: <0747C57B-9640-4296-AF0C-07F923D26BEA@oracle.com> I've been talking for a long time about using value classes for representing cursor-like data, where part of the value is constant (like a base address) and part is variable (like an index). I decided to write up a case study about value-based cursors as a replacement to iterators, as well as with some reflections on how this fits into the larger schemes of Valhalla. Enjoy! http://cr.openjdk.java.net/~jrose/values/iterator-vs-cursor.html ? John -------------- next part -------------- An HTML attachment was scrubbed... URL: From david.holmes at oracle.com Thu Mar 15 09:19:43 2018 From: david.holmes at oracle.com (David Holmes) Date: Thu, 15 Mar 2018 19:19:43 +1000 Subject: Nestmates: JEP 181 CSR request is ready for review In-Reply-To: References: <8f0f0a67-15e9-c44d-7d33-a169de422e2a@oracle.com> Message-ID: After a number of minor editing tweaks to Class and MethodHandles, and the more significant addition of the Security manager checks to Class, the specs have again been updated. http://cr.openjdk.java.net/~dholmes/8010319/specs/ I will propose the CSR request now so that we can start to get feedback from that process. Thanks for all the feedback so far. David On 9/03/2018 6:45 AM, David Holmes wrote: > Thanks Mandy. We'll take the javadoc editing discussion off-list and > I'll come back to the EG when any changes are made. > > David > > On 9/03/2018 5:33 AM, mandy chung wrote: >> >> >> On 3/7/18 11:28 PM, David Holmes wrote: >>> >>> That's an interesting point. Should they also be @CallerSensitive? >>> >> >> Yes. >> >> I hope SM::checkPackageAccess check will be removed some day as we now >> have strong encapsulation. The security team has considered this and >> requires further investigation. >> >>> It may be we have to perform the SM check, but throwing >>> SecurityException is somewhat contrary to the "no exceptions" >>> approach of getNestHost(). >>> >> >> The SecurityException will only be thrown when security manager is >> installed and permission denies.?? Users are responsible to configure >> the security policy to grant proper permission. >> >>> I filed an issue to track this: >>> >>> https://bugs.openjdk.java.net/browse/JDK-8199309 >>> >> >>>> I suggest to make @apiNote in Class::getNestHost as just part of >>>> javadoc. >>>> It can define a section like "Nest Membership" that can be referenced >>> >>> My understanding is that @apiNote et al were introduced to more >>> clearly distinguish between the actual specification part of the >>> Javadoc and other non-normative text. As this is non-normative then >>> @apiNote seems most appropriate. I presume we can still add a tag to >>> allow cross-referencing from inside Class itself. >> >> The definition of a nest is a specification that has no issue to >> include in the javadoc. >>> >>>> by Lookup class spec. >>> >>> Cross-referencing internal text fragments across distinct javadoc is >>> something I thought was not done. ?? >>> >> >> >> >>>> I also have some suggested edits that you can >>>> consider: >>>> >>>> http://cr.openjdk.java.net/~mchung/valhalla/webrevs/nestmates-spec/ >>> >>> Some of these are okay but this part: >>> >>> ? * The source language compiler is responsible for deciding which >>> classes >>> ? * and interfaces are nestmates. For example, the {@code javac} >>> compiler >>> >>> is quite significant and should not be lost. A source compiler is >>> free to chose not to use the new attributes (and of course not >>> benefit from the new access control rules but continue to rely on >>> access-bridges.) So the user of the API has to be aware of this. >>> >> >> This can be retained in @apiNote. >> >>> And in MethodHandles I know there is a dislike of versioning text >>> "Since JDK 11 ..." (though I see this as no different to using >>> @since!), but again this new behaviour may or may not be present >>> depending on the version of the classfiles and the compiler used to >>> create them, so it is critical to me that this is very clearly >>> stated. I suppose this could be re-stated in the form: >>> >>> "If the relationship between nested types is expressed directly >>> through the {@code NestHost} and {@code NestMembers} attributes (see >>> the Java Virtual Machine Specification, sections 4.7.28 and 4.7.29), >>> then the associated {@code Lookup} object provides direct access to >>> the lookup class and all of its nestmates. Otherwise, access between >>> nested classes is obtained by the Java compiler creating a wrapper >>> method to ..." >>> >> >> This is fine too. ? I still think a @linkplain to Class#nestmates >> would be useful. >> >> Mandy >> >>> Thanks, >>> David >>> >>>> Mandy >>>> >>>> On 3/6/18 10:12 PM, David Holmes wrote: >>>>> The Nestmates CSR request: >>>>> >>>>> https://bugs.openjdk.java.net/browse/JDK-8197445 >>>>> >>>>> has been prepared by Dan Smith and myself. Before Proposing this >>>>> CSR request it needs to have Reviewers add themselves to it. >>>>> >>>>> (The first reviewer will need to edit the issue to enter their >>>>> OpenJDK user name in the "Reviewed by" field. Subsequent reviewers >>>>> can simply click on the "Reviewed by" field in the "People" section >>>>> and add their user name. >>>>> >>>>> The CSR contains links to all the updated specification documents, >>>>> all of which have been previously sent out for review/comment to >>>>> the EG (and observers). >>>>> >>>>> Thanks, >>>>> David >>>> >> From karen.kinnear at oracle.com Mon Mar 26 21:33:33 2018 From: karen.kinnear at oracle.com (Karen Kinnear) Date: Mon, 26 Mar 2018 17:33:33 -0400 Subject: Valhalla EG notes March 14, 2018 Message-ID: <988DFB82-9310-45B4-A154-7F9A2427BCC3@oracle.com> attendees: David Simms, John, Frederic, Dan S, Tobi, Dan H, Remi, Karen apologies for not noting the meeting time change in US/Canada relative to Europe - should be all set now Corrections as always - welcome AIs: John: Check Nashorn usage of BSM with Object as 1st parameter John: email proposal about usage of MethdHandle for ldc including usage examples All: review https://bugs.openjdk.java.net/browse/JDK-8171335- - dynamic nestmates (+) proposal - read it through - comments have updated the proposal from the initial description All: John issued a challenge - non-vacuous meaning of final for Value Types I. Condy Dan S - are folks ok with the BSM descriptor change - distinguishing with Lookup as 1st parameter, and throwing error if not to allow this as a future differentiator? Karen: Lois, Karen ok Dan H: decreases ability to use BSM with Object today - expect this is vanishingly small use case - so OK What about Nashorn usage? John : AI: check Dan H: believe JRuby started with Lookup John: in practice - this could be an unambiguous distinguisher for condy - since it is new for indy - if we adopt the restriction they can be similar alternative: we could add a new combinator in front of a new BSM with a new protocol to get the new capability Dan S: condy is often simpler to create, creating a CallSite is more complex John: today: condy is adding an invocation to do what we wanted the VM to do for us Brian has an example in Amber handling symbolic expressions creating syntax trees, with an BSM per level of expression, all named ?invoke? - which is a ?smell? A bigger cleanup would combine all three invokes into one, i.e. a multi invoke BSM with args perhaps 1 multiinvoke BSM with constants and delimiters in the right order which invokes an expression tree no longer 1:1 CP entry to function call we may not need the VM to cache the intermediate steps Dan S: the natural way to express syntax trees in the the CP is to have each node with its own constant and BSM map John: need ways to deal with sub-expressions John: another future idea invoke dynamic constants to be LDC able - i.e. to return a MethodHandle rather than a CallSite completes a matrix: constants have 2 forms: 1 field type, 1 method type indy constant: MethodType type (actually MethodHandle) if indy constant mentions a MethodType give me a MethodHandle with signature ldc - invoke exact or ldc -> MethodHandle behavior want JVM to ensure signature is an exact match Dan H: Is the MethodHandle a dynamic invoker invoked through the CallSite or a 1 time? John: dynamic invoker as if a free floating CallSite as a forward compatibility direction - allow indy BSM to return a MethodHandle as well as CallSites if need a CallSite and get MethodHandle - wrap a constant CallSite around it note: Mutable CallSites - used by dynamic languages - only work for indy and are not in the CP [ed. note - is that accurate? an indy BSM can not return a Mutable CallSite?] Dan H: If VM creates the CallSite - no one could change it if no references leak Karen: indy BSM today is not shareable, ldc has 1:1 CP entry and resolved value would a BSM for ldc MH be shareable? John: [ed. note - missed the answer?] Karen: who creates the CallSite if ldc resolves to a MethodHandle? John: Not the VM Dan H: already have condy, struggling to find use case John: get MH w/signature w/out creating asType and MH constant Dan S: Lambda produces a MH John: we can do this with condy today but it neds an extra layer - could reduce noise in CP Karen: is there a write up? John: AI: email a proposal Dan S: With BSCI, one of the goals is to move the complexity to the library John: concept of a ?butterfly network? Allow any use case to use any constants - relative to field and method types. Move the type mixups to low levels of library code Dan H: does this negate the need for condy? John: VM has a natural type system - with separate field types and method types represented in the CP and bootstrap level combinators, pattern matchers, lambdas - still work with j.l.Class and j.l.MethodType which are the reflected field and method types where possible, nice to have a low level approach that works for both one doesn?t reduce to the other except for simulators Dan H: aware we can do this easily, where do users see this? John: users are classfile translation strategy designers, currently using lots of MH want to create expression trees out of field types and invocation Karen: can you provide examples? Dan H: yes please Remi: concerns: not want two different ways to do the same thing - will send comments in reply to the minutes II. Nestmates Karen : Sealed classes will not make JDK 11 Dynamic nestmates - exploring - possibly part for JDK 11 https://bugs.openjdk.java.net/browse/JDK-8171335 Proposed approach: extend MethodHandles.Lookup Karen: summary Goals: 1. Create dynamic nestmates For static nestmates, explicitly designed so that the NestHost ?authorizes? NestMembers. For dynamic nestmates, propose using providing a Lookup with appropriate mode on the NestHost as authorization to create a NestMate John pointed out we need to distinguish between a Private Lookup and a Full Power Lookup and we need to have that conversation for appropriate mode here. In JDK9 we added a Lookup.defineClass with Package mode which allows defining a class within a package. Intention is to extend this to allow defining a dynamic Nestmate with the same capabilities as a static nestmate, with the exception that the java.lang.Class.getNestMembers()? will only return the statically declared members. Dan H pointed out: we will need an API to get the dynamic members 2. evolve unsafe.DefineAnonymousClass to a supported mechanism Proposal is to extend Lookup.defineClass with the appropriate mode to allow - defining an UNNAMED class - i.e. not findable in the SystemDictionary - defining a TEMPORARY class - which must also be UNNAMED - allowing class unloading on a different lifecycle than the creator or host See RFE: https://bugs.openjdk.java.net/browse/JDK-8171335 The intention is that the three flags/enums: NESTMATE, UNNAMED, TEMPORARY are independent, so you can use this to create non-nestmates. Need to look at the required Lookup modes and make a matrix. In addition, there is a proposal to replace the constant pool patching with the ability to pass in a single live type which is as if you had a pre-initialized static, not in the constant pool, which can only be retrieved via an API on the Lookup. Dan H: is this live type necessary given condy? John: yes - you need at least one object reference which you can inject in a class to associate with user data so that you have this when you run the static initializer Dan H: note: never implemented the constant pool patching for unsafe.DefineAnonymousClass - never found a use for it. John: relates to condy condy does symbolic resolution from the current class? context this mechanism can have a different context Dan H: users could have a condy BSM which they write themselves John: only via symbolic references - if the class is temporary, i.e. has no name - they would need a local namespace shared between the definer and the defined class itself Dan H: or a common named class to communicate through John: concerns about race conditions and privacy problems, this is not a class loader isolation model which is considered less safe today Dan H: how look up live data? John: method call on Lookup on your own class - no one else can get to it as if injected class has an extra static variable pre-initialized library API: getUserData, not getStatic if you can think of another way to initialize a private static final variable with a value that is unnamed and unknown to the definer (and not trust thread locals) Dan H: sounds similar to ClassValue John: alternative trick? Can?t print if it is not yet loaded Remi: or thread local John: assume initiating loader Karen: intentional - not required to be seen by initiating loader? John: this is a live class, avoid name/symbolic reference, not required to be in a shared namespace Remi: want to ensure that when the class? lifecycle is over, the live type is not kept alive John: for class lifecycle - ensure UserData can be acted. UserData lifecycle should not keep the class alive. [ed. note - I added that note to the RFE] John: computed before class is defined as if set static before class initializer is run Remi: use case - AST - want to pass in with bytecode John: could serialize AST into CP of the new class Remi: would have to reconstruct and lose profile data Karen: you are using the CP patching today, right? Remi: yes John: Remi - ok with you to replace with UserData? Remi: yes III. lworld JohnL not expect to play a big role with value types, it is a Object initializer, moving toward factory methods Remi: need to test Srikanth?s changes for withfield syntax John: repurpose constructor syntax Remi: could use static methods Karen: checked with verifier - ok to reuse name if helpful ?final? value type fields: John: can we skip marking value type fields as ?final? - no benefit - might want to have meaning in future Dan H: expected the other way - preserve final now so semantics don?t change if future more options Remi: javac use final to detect changing a field of VT John: benefit of final bit? Remi: vm - no, javac -yes Dan H: if we take it away in future, it will need to be meaningful John: potential future option: not stateful values final for Object means can only be set in a constructor (write once) westfield means withfield state changes only in constructor Dan H: that is a discussion of the scope of withfield John: constructor or nest? if final means restrict setting - nonfatal could allow setting based on access controls always do Copy-on-Write who is allowed to replace single fields? Remi: that is a class level, not a field level decision John: final - want smaller than class, maybe just constructors? Remi: that would change the meaning of final - change all reflection and all tools that process bytecodes Dan H: VM would require a known factory? John: codes like a class - marker for all classe - final allows limited writers use cases - e.g. serialization - that need to set final fields outside of a constructor Remi: they could call a constructor John: simulation of ?new? bytecode - e.g. Cloneable - no way to clone all final fields writing up Reconstructor/Deconstructor Reconstructor - like a constructor - acts as a factory secretly temporarily cloning object and patch new fields even if final Remi: how to create factories on VT - see if they will apply to Object rather than changing semantics of final base this on withfield access John: if final means access to withfield - maybe another modifier bit for new tricks Question: if final in VT fields now - what would be the meaning if unset in future? Dan S: bar higher if unset by default precedent: classfile has redundant info for consistency require opt-in Remi: clone - is a class level decision, not a field decision look at the class semantics for the new modifier John: final-withdraw set operation: objects: putfield, values: withfield Dan S: final bit for VT: default put final - i.e. not mutable John: can be mutated? what about a field initializer? Create a constant for a field? No. Dan S: sort out with VT how to interpret nonfinal vs. final John: challenge - find non-vacuous meaning for final for VT - which have different physics Remi: plenty of modifiers can use - at the class level, not the field level e.g. volatile John: volatile - need atomic marking - use ACC_VOLATILE? Remi: use a different bit if you want a different semantic - first get a clear design of a factory John: another model: withfield allows setting with no side effects nesmates can use withfield - not confined to factories/constructors/reconstructors final means can?t use withfield outside nest RemiL VM vs. Reflection & JDK: can?t call set on it DanH: putfield will not verify on a value type John: link time will throw ICCE thanks, Karen