From karen.kinnear at oracle.com Tue Jun 11 21:39:10 2019 From: karen.kinnear at oracle.com (Karen Kinnear) Date: Tue, 11 Jun 2019 17:39:10 -0400 Subject: Valhalla EG minutes June 05, 2019 Message-ID: <8445F6FB-B1A5-48B2-9A23-AAB76C1CB7AC@oracle.com> Attendees: Remi, Tobi, Dan H, Karen AI: Remi - a request for a specific use case for indy with expression mode BSM if you could I. Valhalla Generics Remi: Are there any intermediate steps between LW10 Erased Generics and LW100 Specialized Generics? e.g Can we get reification without specialization of constant pools or bytecodes? Karen: Who needs to know? Is the generic signature sufficient as available to Reflection? Dan: Current strategy: type arguments create a specialized class Is this similar to the token passed in with unsafe.DefineAnonymousClass? Remi: (ed note - I can?t parse my notes) Dan: At callsites, we do not have the type arguments Remi: At creation site we need the type arguments. If we propagate the type arg when we create a new instance, that is enough by itself Dan: We don?t have sufficient information to propagate the full type argument, the plan was to create an instance of a species Remi: Still need a species, some values are not accessible from the constant pool Karen: What do you mean by ?without specialization? if you have species? Remi: With full specialization, reference to a method requires the fully specialized type descriptor. The step before: There is access to the type arguments in the species, but no constant pool constants depend on them. Think of the type args as stored in the CP. Karen: If we don?t have species, then we need a side channel, and this is not an intermediate step. Dan: It would be a lot of work to pass side channel information with ?same type?. This work is not an intermediate step on the path. Karen: What is the use case if you don?t have different fields and different methods? Remi: goal: support for other languages - so they can encode the type parameter system in the constant pool and model other type systems concern: specialization models java specific semantics in the bytecode II. Records and Sealed Types - JEP https://bugs.openjdk.java.net/browse/JDK-8222777 Exploring for post-JDK13 IIa. Records Karen summarized JVM perspective - but read the JEP for the real information Records: data record compact syntax - class which is a transparent holder of shallowly immutable data declare state - looks like a constructor signature - automatically derive: private final field for each component, public constructor, equals/hashCode:(same type & same state), toString - with all components and names JVMS changes: Format of record_params attribute - initial prototype record_params_count Record_param record_params[count] Record_param name_index access_flags descriptor_index signature_index Expect to also allow annotations on components Karen questions: Are there any required consistencies between e.g. component access and e.g. field access? Are there any duplications of flags or attributes? JVM only needs to know about record class information from the class file in order to pass this through to Reflection. There is no JVM enforcement at this time. Remi: Will the Record attribute have any notion of order or guarantee order of fields? Karen: NO - runtime determines layout Remi: Will the order of components of the Record be the same as you get for Reflection? Dan: Reflection spec says we do not guarantee a specific order Remi: Not for the fields and methods, but for the components Can Reflection see the components at runtime? Karen: yes Remi: Can you get components both by order and by name? - like Scala/Kotlin/C# Dan: Record declaration is syntactic sugar Remi: But it is recorded as an attribute in the bytecode Dan: mostly for javac Remi: also fo Reflection Remi: Want pattern matching - way to extract a value from a record, want to encode in bytecode by name or position (which requires guaranteed order) if only by name - we have binary compatibility, not source compatibility Karen: I doubt the intention here is to provide positional referencing - Brian, do you have an answer for Remi? IIb. Sealed Types: same JEP: JEP https://bugs.openjdk.java.net/browse/JDK-8222777 Karen summary: Sealed types: subclasses restricted according to guidance specified with the type?s declaration User Model: ?sealed? modifier with optional permits list - permits must be in the same module. If this is the unnamed module, permits must be in the same package ed note: goal of this is to reduce separate compilation inconsistencies - if permits list is omitted: compiler can infer from the current compilation unit Defaults: abstract subtypes of sealed types are implicitly sealed concrete subtypes of sealed types are implicitly final You can explicitly modify the subtype with a ?non-sealed? modifier Clarification: sealed is shallow, only applies to direct subtypes Prohibits subtypes which are nameless - i.e. java anonymous subclasses and lambdas (and future Lookup.defineClass - hidden/non-findable - whatever we end up calling it) Remi: What about separate compilation? Can we ensure that the language and JVM constraints are the same? Remi: Propose - must be in the same nest - since vm has no notion of compilation unit Dan: It might not be intended that all the sealed subtypes have access to private members Remi: Agreed - orthogonal: sealed and nestmates Remi: Might want to restrict sealed to same compilation unit - or might not Remi: Can you dynamically update the permit list? Karen: I had the same question - today the answer is no Remi: ok with no, please be explicit in the JEP not planning to support mocking Karen: Propose we consider disallowing JVMTI redefineclasses to modify permitted subtype list Karen: prototype - use ACC_FINAL and a new permitted attribute I was concerned about the concept of final for restricted subtyping I believe John was concerned that if a third-party tool loses the permitted attribute because they don?t yet support it, they are not likely to lose ACC_FINAL, so less risk, euro on side of secure. Dan: Lost 1/2 of your information. If you add agents into the picture, this is not really a security argument Remi: Asm: default keeps all attributes Dan: Any new feature, tools must be updated Remi: If a tool doesn?t recognize a class file version, it should not operate on it Karen: runtime: reject at defineClass time attempts to load a subclass not in the permitted attribute Remi: Not eagerly load permitted subtypes III. Condy and Indy changes - BootstrapMethod new modes Karen summary: From November 2017, we were exploring two new BSM modes. This is the current update. Exploring for post-JDK13 User model goals: New uses of BSMs: I. Lookup/BSCI request: indy and condy (BootStrapCallInfo (vm uses BCI as bytecode index)) Use cases: 1. Allow BSM authors to design extensible APIs in a binary compatible way, without having to have more and more bootstrap variants. 2. Allow a BSM that works with either indy/condy e.g. replace generation of indy with ldc for the case in which a lambda does not capture and the BSM would have returned a ConstantCallSite VM Request: rather than Lookup/String/TypeDescriptor/Object prefers BSM(Lookup/BSCI) for Condy with a static BSM method. (today - with eager resolution of static arguments) II. Expression Mode BSM: No Lookup: condy only 1. Allow BSM authors to use regular method signatures, with no Lookup so APIs can be used in other places as well e.g. javac: generate condy for references to pattern extractors III. Farther Future - lazy resolution of arguments (if asked) use cases: - e.g. performance: BSM generates bytecodes, and BSM needs to reflect over e.g. MH/MT arguments. Could be useful to just deliver unresolved types (rather than resolve/revealDirect) - sometimes not all arguments are resolvable We will explore possibilities here in future. ConstantDesc and subtypes offer a way to handle this, as long as you can get a Lookup for resolution, so one approach would be for the author to use Lookup/BSCI and return a ConstantDesc for lazy resolution. === JVMS Changes for BSM modes: 0. existing BSM(lookup, name, type, ...) always eager 1. BSCI Lookup, BSCI identified by 2 arguments, first is a Lookup for Condy and Indy initially all arguments statically resolved 2. BSM with no Lookup, name, type - Expression Mode For condy only identified by no initial lookup goal: ordinary static methods for BSMs Dan: Do both modes apply to condy and indy? Karen: BSM with no Lookup, name, type is currently targeted for condy only. Remi: Does not like having the expression mode be for condy only. use case for indy: Clojure runtime - would like to do more lazy loading of BSM static arguments for indy another use case for indy for a constant - might want to add constraints or security checks each time you resolve Karen: I think the only reason we did not plan expression mode for indy was no use cases. Remi: For the goal of sharing a BSM for both condy and indy, you can do that today using Object as super class of MethodType Karen: We are proposing to phase in BSM mode handling. The next step does not have a lazy resolution mode. Note that the author of the BSM has a workaround to support lazy resolution now that ConstantDesc exists, so we would like to see how far that can go. Dan: What about class redefinition? Karen: might want to think about disallowing removing BSM attribute entries with class redefinition. Dan: Only allow adding BSM attribute entries? Karen: we could either enforce this with the redefinition JVMTI spec or the vm might need to implement it internally Karen: We also need to think about add-exports which can change an error return into a success case Both the redefinition and add-exports issues get more complex with lazy resolution. Dan: Last conversation with John about lazy resolution via Constable, the results were not written back to the constant pool. Ed. note - still the case, although there is caching - need to study in more detail relative to result consistency expectations Remi: Would like a Constable for String - so we could have a lazy string Karen: I thought String was resolved like any primitive today. Why would you want that lazily resolved? Remi: e.g. if the String is a secret that you don?t want stored in memory before resolved Karen: you could use a class or in future an inline class - since you want a binary blob in the constant pool, rather than a String Dan: This is not a feature you want IV. Value Types static init factories and withfield Tobi: what is the scope/restrictions for withfield? Karen: nestmates I think ed. note - double-checked: yes, restricted to nestmates Remi: yes, you want withfield to work inside instance methods not just in factories Corrections welcome, thanks, Karen From daniel.smith at oracle.com Thu Jun 13 20:57:31 2019 From: daniel.smith at oracle.com (Dan Smith) Date: Thu, 13 Jun 2019 14:57:31 -0600 Subject: Draft LW2 spec Message-ID: <5FF324CD-6034-4E7C-8221-8057FDAD86E9@oracle.com> Here's a first look at a preview-feature-quality spec for values^H^H^H^H^H^Hinline classes. http://cr.openjdk.java.net/~dlsmith/inline-classes/specs/jvms-inline-classes.html It reflects my understanding of what LW2 is supposed to look like. I'm sure I've gotten out of sync on some things, so please take some time to check on things I might be missing. There are a few "design discussion" blocks that identify areas that may evolve further (in LW3, say) or where the design choices we've settled on aren't necessarily essential. One area that required making some nontrivial choices, and could use some extra scrutiny, is the treatment of preparation and initialization. We know there are some invariants we want enforced, but there's a lot of wiggle room in deciding how they are enforced. Note that I've included a suite of bug fixes/presentational improvements in a separate document, linked to in the introduction. If you notice differences between the official JVMS text and the text I'm quoting, that's probably why. I don't think most people will be interested in those details, but if you are, feel free to review the second document as well! From forax at univ-mlv.fr Fri Jun 14 08:54:43 2019 From: forax at univ-mlv.fr (Remi Forax) Date: Fri, 14 Jun 2019 10:54:43 +0200 (CEST) Subject: Draft LW2 spec In-Reply-To: <5FF324CD-6034-4E7C-8221-8057FDAD86E9@oracle.com> References: <5FF324CD-6034-4E7C-8221-8057FDAD86E9@oracle.com> Message-ID: <299125818.1413090.1560502483805.JavaMail.zimbra@u-pem.fr> Hi Daniel, section 4.1: in the table 4.1-A, 13/57/45..57 is missing given you talk about later in this section. section 4.3.2: I don't think that using null as a diferentiator (Nullable/NonNullable) is a good idea. Yes, an inline type is not nullable, but it's also flattenable, loaded early, not circular, etc. This introduce a false dichotomy which we have already spent too much time. I don't remember the exact words that John is using, but it was making more sense too me. Perhaps only renaming NullFreeClassType to InlineClassType is enough ? section 4.10.1.2: the bottom right of the schema is wrong because a reference type can be a nullable type or an inline type which is not nullable I propose reference type / \ / \ nullable type inline class | | null R?mi > De: "daniel smith" > ?: "valhalla-spec-experts" > Envoy?: Jeudi 13 Juin 2019 22:57:31 > Objet: Draft LW2 spec > Here's a first look at a preview-feature-quality spec for > values^H^H^H^H^H^Hinline classes. > [ > http://cr.openjdk.java.net/~dlsmith/inline-classes/specs/jvms-inline-classes.html > | > http://cr.openjdk.java.net/~dlsmith/inline-classes/specs/jvms-inline-classes.html > ] > It reflects my understanding of what LW2 is supposed to look like. I'm sure I've > gotten out of sync on some things, so please take some time to check on things > I might be missing. > There are a few "design discussion" blocks that identify areas that may evolve > further (in LW3, say) or where the design choices we've settled on aren't > necessarily essential. > One area that required making some nontrivial choices, and could use some extra > scrutiny, is the treatment of preparation and initialization. We know there are > some invariants we want enforced, but there's a lot of wiggle room in deciding > how they are enforced. > Note that I've included a suite of bug fixes/presentational improvements in a > separate document, linked to in the introduction. If you notice differences > between the official JVMS text and the text I'm quoting, that's probably why. I > don't think most people will be interested in those details, but if you are, > feel free to review the second document as well! From daniel.smith at oracle.com Fri Jun 14 16:56:40 2019 From: daniel.smith at oracle.com (Dan Smith) Date: Fri, 14 Jun 2019 10:56:40 -0600 Subject: Draft LW2 spec In-Reply-To: <299125818.1413090.1560502483805.JavaMail.zimbra@u-pem.fr> References: <5FF324CD-6034-4E7C-8221-8057FDAD86E9@oracle.com> <299125818.1413090.1560502483805.JavaMail.zimbra@u-pem.fr> Message-ID: > On Jun 14, 2019, at 2:54 AM, Remi Forax wrote: > > Hi Daniel, > > section 4.1: in the table 4.1-A, > 13/57/45..57 is missing given you talk about later in this section. That's not a change this feature is responsible for, but you're right that it needs to be changed. We have this awkward bootstrapping problem, where the document as it's being developed is built on top of 12, but eventually needs to be rebased to 13. Now that JVMS 13 is final, I could take a stab at rebasing everything. > section 4.3.2: > I don't think that using null as a diferentiator (Nullable/NonNullable) is a good idea. > Yes, an inline type is not nullable, but it's also flattenable, loaded early, not circular, etc. This introduce a false dichotomy which we have already spent too much time. I don't remember the exact words that John is using, but it was making more sense too me. > Perhaps only renaming NullFreeClassType to InlineClassType is enough ? I'll think more about this terminology. "Inline class type" is not sufficient, because QVal; and LVal; are *both* inline class types. > section 4.10.1.2: > the bottom right of the schema is wrong because a reference type can be a nullable type or an inline type which is not nullable > I propose > > reference type > / \ > / \ > nullable type inline class > | > | > null Yep. I was hoping I could get away with some hand-waving. Guess not. :-) The struggle here is that "reference type hierarchy" is meant to be a black box. I guess one way to make this work is to put 'null' in the box and remove it from the diagram. Another way is to break open the box, as you've done, but note that then you've got informal descriptions of types in a diagram that otherwise talks explicitly about specific types, and it's a lost cause trying to appropriately model the relationships between those informal descriptions (e.g., each inline class type is a subtype of some nullable types). From forax at univ-mlv.fr Fri Jun 14 19:03:54 2019 From: forax at univ-mlv.fr (forax at univ-mlv.fr) Date: Fri, 14 Jun 2019 21:03:54 +0200 (CEST) Subject: Draft LW2 spec In-Reply-To: References: <5FF324CD-6034-4E7C-8221-8057FDAD86E9@oracle.com> <299125818.1413090.1560502483805.JavaMail.zimbra@u-pem.fr> Message-ID: <466738446.1625050.1560539034300.JavaMail.zimbra@u-pem.fr> ----- Mail original ----- > De: "daniel smith" > ?: "Remi Forax" > Cc: "valhalla-spec-experts" > Envoy?: Vendredi 14 Juin 2019 18:56:40 > Objet: Re: Draft LW2 spec >> On Jun 14, 2019, at 2:54 AM, Remi Forax wrote: >> >> Hi Daniel, >> >> section 4.1: in the table 4.1-A, >> 13/57/45..57 is missing given you talk about later in this section. > > That's not a change this feature is responsible for, but you're right that it > needs to be changed. > > We have this awkward bootstrapping problem, where the document as it's being > developed is built on top of 12, but eventually needs to be rebased to 13. Now > that JVMS 13 is final, I could take a stab at rebasing everything. it's a side effect of the new release cadence and 14 is around the corner ... > >> section 4.3.2: >> I don't think that using null as a diferentiator (Nullable/NonNullable) is a >> good idea. >> Yes, an inline type is not nullable, but it's also flattenable, loaded early, >> not circular, etc. This introduce a false dichotomy which we have already spent >> too much time. I don't remember the exact words that John is using, but it was >> making more sense too me. >> Perhaps only renaming NullFreeClassType to InlineClassType is enough ? > > I'll think more about this terminology. "Inline class type" is not sufficient, > because QVal; and LVal; are *both* inline class types. is it not better to try to separate the type notion from the class notion ? L and Q are type, L is an identity type, Q an inline type and at runtime an inline class can be typed as an identity type (L) or an inline type (Q). > >> section 4.10.1.2: >> the bottom right of the schema is wrong because a reference type can be a >> nullable type or an inline type which is not nullable >> I propose >> >> reference type >> / \ >> / \ >> nullable type inline class >> | >> | >> null > > Yep. I was hoping I could get away with some hand-waving. Guess not. :-) > > The struggle here is that "reference type hierarchy" is meant to be a black box. > I guess one way to make this work is to put 'null' in the box and remove it > from the diagram. Another way is to break open the box, as you've done, but > note that then you've got informal descriptions of types in a diagram that > otherwise talks explicitly about specific types, and it's a lost cause trying > to appropriately model the relationships between those informal descriptions > (e.g., each inline class type is a subtype of some nullable types). R?mi From brian.goetz at oracle.com Fri Jun 14 19:16:01 2019 From: brian.goetz at oracle.com (Brian Goetz) Date: Fri, 14 Jun 2019 15:16:01 -0400 Subject: Draft LW2 spec In-Reply-To: <5FF324CD-6034-4E7C-8221-8057FDAD86E9@oracle.com> References: <5FF324CD-6034-4E7C-8221-8057FDAD86E9@oracle.com> Message-ID: <9a2be2a1-4da6-c741-035f-620b45c16722@oracle.com> > > There are a few "design discussion" blocks that identify areas that > may evolve further (in LW3, say) or where the design choices we've > settled on aren't necessarily essential. Here's a few more: ?- The ACC_INLINE bit may well go away if we settle on a RefObject / ValObject hierarchy; then a class is an inline class iff it extends ValObject.? (In the current formulation, I think you want to add in INLINE -> !INTERFACE too.) ?- NullFreeClassType may prefer to be called something else; this is the "new contract" story John is working on.? And some "new contract" types may be nullable as well, if we go forward with the null-default story. From daniel.smith at oracle.com Fri Jun 14 20:09:32 2019 From: daniel.smith at oracle.com (Dan Smith) Date: Fri, 14 Jun 2019 14:09:32 -0600 Subject: Draft LW2 spec In-Reply-To: <466738446.1625050.1560539034300.JavaMail.zimbra@u-pem.fr> References: <5FF324CD-6034-4E7C-8221-8057FDAD86E9@oracle.com> <299125818.1413090.1560502483805.JavaMail.zimbra@u-pem.fr> <466738446.1625050.1560539034300.JavaMail.zimbra@u-pem.fr> Message-ID: <653C3B9A-6380-48C0-92E0-11BD7F8E8502@oracle.com> > On Jun 14, 2019, at 1:03 PM, forax at univ-mlv.fr wrote: > >>> section 4.3.2: >>> I don't think that using null as a diferentiator (Nullable/NonNullable) is a >>> good idea. >>> Yes, an inline type is not nullable, but it's also flattenable, loaded early, >>> not circular, etc. This introduce a false dichotomy which we have already spent >>> too much time. I don't remember the exact words that John is using, but it was >>> making more sense too me. >>> Perhaps only renaming NullFreeClassType to InlineClassType is enough ? >> >> I'll think more about this terminology. "Inline class type" is not sufficient, >> because QVal; and LVal; are *both* inline class types. > > is it not better to try to separate the type notion from the class notion ? > L and Q are type, L is an identity type, Q an inline type and at runtime an inline class can be typed as an identity type (L) or an inline type (Q). We're settled on what "inline class" means: a class with the ACC_INLINE flag. Given that, I think it's hopeless to try to use the term "inline class type" to mean anything other than "a class type naming an inline class". (And "class type" means "a type that names a class".) As for "identity type": inline class instances do not have identity, so it would not make sense to consider them to have an "identity type". We do not want to be reinforcing the bias people will already bring that says all Objects and interface instances have identity. From daniel.smith at oracle.com Fri Jun 14 20:15:29 2019 From: daniel.smith at oracle.com (Dan Smith) Date: Fri, 14 Jun 2019 14:15:29 -0600 Subject: Draft LW2 spec In-Reply-To: <9a2be2a1-4da6-c741-035f-620b45c16722@oracle.com> References: <5FF324CD-6034-4E7C-8221-8057FDAD86E9@oracle.com> <9a2be2a1-4da6-c741-035f-620b45c16722@oracle.com> Message-ID: <379E9069-FFEB-4C9C-B2A9-5A39E20A0308@oracle.com> > On Jun 14, 2019, at 1:16 PM, Brian Goetz wrote: > >> There are a few "design discussion" blocks that identify areas that may evolve further (in LW3, say) or where the design choices we've settled on aren't necessarily essential. > > Here's a few more: > > - The ACC_INLINE bit may well go away if we settle on a RefObject / ValObject hierarchy; then a class is an inline class iff it extends ValObject. (In the current formulation, I think you want to add in INLINE -> !INTERFACE too.) I'm a little skeptical (compare usage of ACC_ENUM, even though Java enforces that the superclass is java.lang.Enum), but, yes, I can mention that the flag isn't the only possible way to encode the information. (Thanks for catching the ACC_INTERFACE interaction, which I'll fix.) > - NullFreeClassType may prefer to be called something else; this is the "new contract" story John is working on. And some "new contract" types may be nullable as well, if we go forward with the null-default story. Yes, that's a bigger, more open-ended discussion than I want to squeeze into a box, but I can add something to suggest the null-free/nullable barrier may evolve in the future. From daniel.smith at oracle.com Tue Jun 18 23:56:16 2019 From: daniel.smith at oracle.com (Dan Smith) Date: Tue, 18 Jun 2019 17:56:16 -0600 Subject: Draft LW2 spec In-Reply-To: <5FF324CD-6034-4E7C-8221-8057FDAD86E9@oracle.com> References: <5FF324CD-6034-4E7C-8221-8057FDAD86E9@oracle.com> Message-ID: <93AAA6BE-CA40-47E6-A099-DC3EAEF72B52@oracle.com> > On Jun 13, 2019, at 2:57 PM, Dan Smith wrote: > > Here's a first look at a preview-feature-quality spec for values^H^H^H^H^H^Hinline classes. > > http://cr.openjdk.java.net/~dlsmith/inline-classes/specs/jvms-inline-classes.html I've done some tidying up of my cr folder. Please just use this URL now, which redirects to the latest: http://cr.openjdk.java.net/~dlsmith/inline-classes From harold.seigel at oracle.com Wed Jun 19 14:40:53 2019 From: harold.seigel at oracle.com (Harold Seigel) Date: Wed, 19 Jun 2019 10:40:53 -0400 Subject: Draft LW2 spec In-Reply-To: <93AAA6BE-CA40-47E6-A099-DC3EAEF72B52@oracle.com> References: <5FF324CD-6034-4E7C-8221-8057FDAD86E9@oracle.com> <93AAA6BE-CA40-47E6-A099-DC3EAEF72B52@oracle.com> Message-ID: <7a216a64-56c5-4d7f-406f-2d4ca1a720f7@oracle.com> Hi Dan, Doesn't the text concerning , such as the following, need to change because can now have a non-void return type and be called by invokestatic when it is used as a factory method? 4.4.2 ... If the name of the method in a|CONSTANT_Methodref_info|structure begins with a '|<|' ('|\u003c|'), then the name must be the special name||, representing an instance initialization method (2.9.1 ). The return type of such a method must be|void|. Thanks, Harold On 6/18/2019 7:56 PM, Dan Smith wrote: >> On Jun 13, 2019, at 2:57 PM, Dan Smith wrote: >> >> Here's a first look at a preview-feature-quality spec for values^H^H^H^H^H^Hinline classes. >> >> http://cr.openjdk.java.net/~dlsmith/inline-classes/specs/jvms-inline-classes.html > I've done some tidying up of my cr folder. Please just use this URL now, which redirects to the latest: > > http://cr.openjdk.java.net/~dlsmith/inline-classes > From karen.kinnear at oracle.com Thu Jun 20 14:23:12 2019 From: karen.kinnear at oracle.com (Karen Kinnear) Date: Thu, 20 Jun 2019 10:23:12 -0400 Subject: Draft LW2 spec In-Reply-To: <93AAA6BE-CA40-47E6-A099-DC3EAEF72B52@oracle.com> References: <5FF324CD-6034-4E7C-8221-8057FDAD86E9@oracle.com> <93AAA6BE-CA40-47E6-A099-DC3EAEF72B52@oracle.com> Message-ID: <969641A0-7E8C-45C1-ABF3-FB50931E6EB7@oracle.com> Dan, Many thanks for putting out a draft JVMS for LW2. Folks - if you could be explicit in review comments whether they are relevant to LW2 or to post-LW2, e.g. design discussions, that would help. LW2 comments: 1. Versioning Thank you for asking. For LW10, we plan to use preview versioning. For LW2, we just use JDK13 cfv 57 2. 2.4 Reference Types and Values Bullet defining Array component type "the element type of a multi-dimensional array is the element type of its component type" - it is no longer clear that the element type is not the next dimension down, but the final one that is not itself an array 3. 4.4.1 The CONSTANT_Class_info Strtucture "In a class file whose version number is not 57.65535, the name_index item must not be a field descriptor of the form NullableClassType or NullFreeClassType." Actually, since NullableClassType replaced ClassType - isn't it just NullFreeClassType that is not ok? 4. 4.6. Methods name_index "The value of the name_index item must be a valid index into the constant_pool table. The constant_pool entry at that index must be a CONSTANT_Utf8_info structure (4.4.7) representing either a valid unqualified name denoting a method (4.2.2), or (if this method is in a class an identity class or the Object class rather than an inline class or an interface) the special method name , or the special method name ." ? LW2 was changed: now have for inline classes. We also have . 5a. 5.4.3.1 Class, Interface and Reference Type Resolution Any attempt to resolve a reference to a null-free inline type, that resolves to a non-inline type, throws an ICCE at resolution time. For example, this is used by 6.5 defaultvalue. I would assume you want to put this in 5.4.3.1, but you could put this in 6.5 defaultvalue. The implementation puts this in 5.4.3.1 equivalent. 5b. 4.9.1. Static Constraints "Every defaultvalue instruction must reference a constant pool entry of kind CONSTANT_Class that represents a null-free class type.? In anticipation of evolution of defaultvalue to handle null-default inline types, and possibly to handle nullable inline types, and in an effort to not add additional eager loading for the verifier, for LW2, we removed the verifier checks for defaultvalue enforcing a null-free class type and moved the check to runtime.and new bytecodes relative to null-free and inline classes. 6. 5.4.2. Preparation (discussion topic for EG) Part I: Method descriptors: JVMS LW2 draft specifies that the declared method ptypes marked as null-free are loaded as part of preparation, including throwing ICCE if not an inline class. We have had previous discussions with IBM - I think we want some verbiage to allow eager or lazy resolution of method ptypes which are null-free inline types. Hotspot needs to load these as part of linking (we can discuss if this is part of preparation or not later) IBM wants to lazily load at first invocation We all agree on ICCE for a mismatch here. Part II. Field Descriptors: Instance Fields This has to be performed at load time/class definition time - needed for layout. - Not at preparation time - that is too late. I believe we do agree with ICCE and risk of ClassCircularityError if ?flattenable?. Part III. Field Descriptors: Static Fields For LW2, for static fields, we do the same exercise as we do for instance fields, with the same risk of ICCE and ClassCircularityError. See below for potential post-LW2 static field open issue. 7. putfield: Needs updating - now that inline classes support - putfield is not supposed to modify inline class instance fields, even during (being a final field is not sufficient to stop that) - so need IAE if resolved field is a field of an inline class. We don't want verifier to catch since this should apply to both LPoint; and QPoint; post-LW2, design discussion comments: 1. 6.5. monitorenter What is the Design discussion proposing? Would love a solution for this - have not found one that is satisfactory. Design discussion: we might wish, instead, to support inline class instances by associating a monitor with each unique field-value vector. In that approach, two references have the same monitor iff they are acmpeq. Further discussion may be warranted on the choice of exception type to throw. Karen?s concern - about accidental sharing of the same monitor -in the field surprise bugs - hard to reproduce - timing based - e.g. I try to lock but you are holding the lock (but we are running completely independent code) e.g. overlap for wait and notify (customers do not always check conditions for notify) 2. 5.4.2 Preparation Post-LW2 we need to have a discussion on how to handle static fields that are inline types. There are challenges with ClassCircularityIssues even though we have agreed that in practice we don?t actually want to flatten static null-free inline classes. There are also issues with timing of default value creation relative to class load/class initialization/visibility of an instance on which operations can happen, since the class initialization barrier includes new, defaultvalue/anewarray/multianewarray which allows other bytecodes operating on instances to not have an initialization barrier. Frederic has been studying possible ways to deal with issues that occur due to examples such as: example 1: class MyValue: static MyValue; // the degenerate case example 2: class A: static B sb; class B: static A sa; thanks, Karen > On Jun 18, 2019, at 7:56 PM, Dan Smith wrote: > >> On Jun 13, 2019, at 2:57 PM, Dan Smith > wrote: >> >> Here's a first look at a preview-feature-quality spec for values^H^H^H^H^H^Hinline classes. >> >> http://cr.openjdk.java.net/~dlsmith/inline-classes/specs/jvms-inline-classes.html > I've done some tidying up of my cr folder. Please just use this URL now, which redirects to the latest: > > http://cr.openjdk.java.net/~dlsmith/inline-classes > From daniel.smith at oracle.com Tue Jun 25 00:10:29 2019 From: daniel.smith at oracle.com (Dan Smith) Date: Mon, 24 Jun 2019 18:10:29 -0600 Subject: Draft LW2 spec In-Reply-To: <969641A0-7E8C-45C1-ABF3-FB50931E6EB7@oracle.com> References: <5FF324CD-6034-4E7C-8221-8057FDAD86E9@oracle.com> <93AAA6BE-CA40-47E6-A099-DC3EAEF72B52@oracle.com> <969641A0-7E8C-45C1-ABF3-FB50931E6EB7@oracle.com> Message-ID: <0616DCF7-DCB8-4AF9-8562-86CA2ED461DF@oracle.com> > On Jun 20, 2019, at 8:23 AM, Karen Kinnear wrote: > > 1. Versioning > Thank you for asking. > For LW10, we plan to use preview versioning. For LW2, we just use JDK13 cfv 57 Fixed now in my local copy (which I'll share soon). > 2. 2.4 Reference Types and Values > Bullet defining Array component type > "the element type of a multi-dimensional array is the element type of its component type" > - it is no longer clear that the element type is not the next dimension down, but the > final one that is not itself an array How's this? Every array type has a non-array *element type*. The element type of a single-dimensional array type is its component type; the element type of a multi-dimensional array type is the element type of its component type (applying this definition recursively).** > 3. 4.4.1 The CONSTANT_Class_info Strtucture > "In a class file whose version number is not 57.65535, the name_index item must not be a field descriptor of the form NullableClassType or NullFreeClassType." > > Actually, since NullableClassType replaced ClassType - isn't it just NullFreeClassType that is not ok? There are three forms of name_index values: Foo LFoo; QFoo; The latter two are new in 57.0. See the design discussion later in this section: "The strategy used here is to overload CONSTANT_Class_info with null-free class type descriptors. In doing so, there's no particular reason (though we may decide to be more restrictive) that L types can't be supported, too, as an alternative to bare class names in contexts that work on arbitrary types. The only descriptors that can't be allowed, due to syntactic ambiguity, are those for primitive types?supporting primitive types would require new syntax." > 4. 4.6. Methods > name_index > "The value of the name_index item must be a valid index into the constant_pool table. The constant_pool entry at that index must be a CONSTANT_Utf8_info structure (4.4.7) representing either a valid unqualified name denoting a method (4.2.2), or (if this method is in a class an identity class or the Object class rather than an inline class or an interface) the special method name , or the special method name ." > > ? LW2 was changed: now have for inline classes. We also have . I'll work on . Probably will spin it off into a separate document, because it's an orthogonal feature. The sentence is meant to allow for in all cases. It's just phrased awkwardly. > 5a. 5.4.3.1 Class, Interface and Reference Type Resolution > Any attempt to resolve a reference to a null-free inline type, that resolves to a non-inline type, > throws an ICCE at resolution time. > > For example, this is used by 6.5 defaultvalue. > > I would assume you want to put this in 5.4.3.1, but you could put this in 6.5 defaultvalue. > The implementation puts this in 5.4.3.1 equivalent. I put this check in preparation for field/method declarations, but didn't touch other places Q types may appear. I've added it to 5.4.3.1 (Q type as CONSTANT_Class), 5.4.3.3 (Q type in signature-polymorphic method descriptor), and 5.4.3.5 (Q type in CONSTANT_MethodType) in my local copy. The requirement here is that we never try to create a java.lang.Class (or similar internal class object) representing, for example, Qjava/lang/String;. There are also Q types in field and method references. I'm tentatively thinking that mismatches here are harmless, because they'll just result in lookup failures (no field/method with a bad descriptor can be declared). Agreed, or do we want a check somewhere? > 5b. 4.9.1. Static Constraints > "Every defaultvalue instruction must reference a constant pool entry of kind CONSTANT_Class that represents a null-free class type.? > > In anticipation of evolution of defaultvalue to handle null-default inline types, and possibly > to handle nullable inline types, and in an effort to not add additional eager loading for > the verifier, for LW2, we removed the verifier checks for defaultvalue enforcing a null-free class type and moved the check to runtime.and new bytecodes relative to null-free and inline classes. "represents a null-free class type" is a constraint on the syntax, not on the properties of the referenced class. So: every defaultvalue must point to a CONSTANT_Class of the form 'Q...;'. Does that line up with what has been implemented? (For more discussion on why I think we don't want bare class names here, see the 'defaultvalue' spec in 6.5.) > 6. 5.4.2. Preparation (discussion topic for EG) > > Part I: Method descriptors: > JVMS LW2 draft specifies that the declared method ptypes marked as null-free are loaded > as part of preparation, including throwing ICCE if not an inline class. > > We have had previous discussions with IBM - I think we want some verbiage to allow eager or > lazy resolution of method ptypes which are null-free inline types. > > Hotspot needs to load these as part of linking (we can discuss if this is part of preparation or not later) > IBM wants to lazily load at first invocation > > We all agree on ICCE for a mismatch here. Hmm, I'll have to think about where to put this, if not in preparation. I'm sad to give up on "During preparation of a class or interface C, the Java Virtual Machine imposes constraints on field and method descriptors (4.3)"?it seems like a natural fit for all these checks. But if it's important to be able to delay checking Q types in method descriptors, we can probably find a way to specify it. > Part II. Field Descriptors: Instance Fields > This has to be performed at load time/class definition time - needed for layout. > - Not at preparation time - that is too late. > > I believe we do agree with ICCE and risk of ClassCircularityError if ?flattenable?. Same comment?preparation is a nice fit, class creation less so, but if it's what we need I'll see what I can do. > Part III. Field Descriptors: Static Fields > > For LW2, for static fields, we do the same exercise as we do for instance fields, > with the same risk of ICCE and ClassCircularityError. > > See below for potential post-LW2 static field open issue. Ok, fixed in my local copy. > 7. putfield: > Needs updating - now that inline classes support - putfield is > not supposed to modify inline class instance fields, even during > (being a final field is not sufficient to stop that) - so need IAE > if resolved field is a field of an inline class. > We don't want verifier to catch since this should apply to both LPoint; and QPoint; The verifier needs some awareness of this, too, because of the special typing rules for unitializedThis. I think it's straightforward to fix up, and comes down what we mean by "instance initialization method", which is currently interpreted as "method named ''", but can have some additional constraints. > post-LW2, design discussion comments: > > 1. 6.5. monitorenter > What is the Design discussion proposing? > Would love a solution for this - have not found one that is satisfactory. Not proposing anything new! Just trying to document the existing unresolved discussion, if I'm reading where we're at on this correctly. If we want to do something more than throw for an inline class instance, I think what it looks like is basically interning: use a hash table to map instances that are equivalent to a canonical object, except in this case "equivalent" means acmp and the canonical object is a lock rather than another class instance. > Karen?s concern - about accidental sharing of the same monitor > -in the field surprise bugs - hard to reproduce - timing based > - e.g. I try to lock but you are holding the lock (but we are running completely independent code) > e.g. overlap for wait and notify (customers do not always check conditions for notify) Okay, so this is what you mean by not "satisfactory". You don't like "unique" objects held by different people to share the same lock. Which is reasonable to be uncomfortable about, but I also think having no identity means it's a bug to think your object is "unique". Whether this is a bigger violation of user expectations than the behavior of acmp, which also can introduce bugs when users assume uniqueness, is worth more exploration. > 2. 5.4.2 Preparation > Post-LW2 we need to have a discussion on how to handle static fields that are inline types. > There are challenges with ClassCircularityIssues even though we have agreed that in practice > we don?t actually want to flatten static null-free inline classes. There are also issues > with timing of default value creation relative to class load/class initialization/visibility > of an instance on which operations can happen, since the class initialization barrier > includes new, defaultvalue/anewarray/multianewarray which allows other bytecodes operating on instances to not have an initialization barrier. > Frederic has been studying possible ways to deal with issues that occur due to examples such as: > example 1: class MyValue: static MyValue; // the degenerate case > example 2: class A: static B sb; class B: static A sa; I'd like to understand this better. I think I'm happy with what I put in the spec document, but it may be that new issues arise when trying to shift the timing from preparation to creation. From daniel.smith at oracle.com Sat Jun 29 00:45:47 2019 From: daniel.smith at oracle.com (Dan Smith) Date: Fri, 28 Jun 2019 18:45:47 -0600 Subject: Draft LW2 spec In-Reply-To: <93AAA6BE-CA40-47E6-A099-DC3EAEF72B52@oracle.com> References: <5FF324CD-6034-4E7C-8221-8057FDAD86E9@oracle.com> <93AAA6BE-CA40-47E6-A099-DC3EAEF72B52@oracle.com> Message-ID: Updated spec: http://cr.openjdk.java.net/~dlsmith/lw2/lw2-20190628/specs/inline-classes-jvms.html What's new? - Specification for using "" as a regular method name. Lots of choices to be made here, so I'm curious about how what I ended up with compares to what is currently implemented. - Added some discussion blocks in various places, based on feedback. - Changed required version numbers to 57.0. - Static constraints on use of `ACC_INLINE`, declarations of instance initialization methods, and forms of CONSTANT_Class_infos appearing in various attributes and other places. - Prohibited circularities in static field types. - Added resolution checks on Q types in CONSTANT_Classes and CONSTANT_MethodTypes. - Cleaned up the verification type diagram; fixed the verification type of 'this' in inline classes. A few big things left to do, as described in the introduction.