From karen.kinnear at oracle.com Thu Feb 9 22:43:08 2017 From: karen.kinnear at oracle.com (Karen Kinnear) Date: Thu, 9 Feb 2017 17:43:08 -0500 Subject: Initial feedback on Minimal Value Types 0.2 for discussion In-Reply-To: References: <2B1F10B9-45B6-466D-8D4B-A872DA0A01DB@oracle.com> Message-ID: (This is a resend of an email I sent to valhalla-dev at openjdk.java.net on January 23) Review of Minimal Value Types August 2016 Shady Edition (v 0.2) http://cr.openjdk.java.net/~jrose/values/shady-values.html Questions/Comments: abbreviations used: VCC: value-capable class, DVT: derived value type 1. Goals -- might be worth adding to the bullets: Allow use of existing toolchain where possible including IDEs and debuggers 2. Features: "Three" bytecode instructions ->"A small set of" 3. Typically, value-capable classes will not be exported. Is the reason for this to limit exposure since the expectation is that the initial APIs and mechanisms will change? 4. Value-capable classes: supporting methods p.3 "This design endows both boxes and pure values with a common set of methods; it "lifts" box methods onto the derived values." p.5 "The synthetic class has the given fields (unchanged) and has no methods" p.5 "Meanwhile, all methods (and other class features) stay on the value-capable class. The value type proper is just a "dumb struct" containing the extracted fields" - given that in the MVT model we are starting with a POJO box, and instance methods that clearly take an Object as a receiver, one proposal for the initial MVT approach would be to have all methods only supported by the box, and require boxing to invoke any methods - so I think the first quote would need either removal or modification 5. Value bytecodes p.11 "Method handles and invokedynamic will always allow bytecode to invoke methods on Q-types". - is this still accurate in the context above? I know the comment says that internally the MH might box the Qtype, but do we still want to support MH and indy to appear to invoke methods on Q-types? 6. Restrictions on the POJO: A. It would help to have a bulleted list of restrictions B. Clarify error/exception to throw - perhaps ClassFormatError for all of these? C. Request to not support VCC on interfaces at all for MVT 1.0 I know the restrictions are intermixed in the text today. This is what I extracted: (p.3-4, 6) VCC (and probably going forward) 1. VCC superclass must be Object (and should be omitted) 2. the class must be final 3. all fields must be final - please clarify - all instance fields must be final 4. all constructors private 5. must replace equals, hashcode, toString (with current Object syntax) 6. may not use any methods provided on Object specifically: may not use clone, finalize, wait, notify, notifyAll (directly) 7. may use getClass MVT 1.0 additional limitations 9. may contain primitive instance fields, but no reference instance fields - please update document to clarify this restriction is for instance fields only 10. may not contain generic instance fields - please update document to clarify this restriction is for instance fields only - it is my understanding that you can?t have generic static fields at all 11. "interfaces (especially with default methods)" - please change p.6 to clarify that there are no value type interfaces period. 12. 0.2 version states: may not contain a value class as an instance field - see below for further discussion 7. potential extensions: 12. 0.2 version states: value class may not contain a value class as an instance field - we would like to propose supporting this - perhaps as an optional extension? - we would need to add an exception for handling circularity - note: no way to express this in java, but you could express in a classfile 8. Splitting the value type from the object type Propose not using the nested class approach, to not tie us into this relationship longer term - so remove example and the "looks like an inner class" - note: a key point here is how the user generating bytecodes would know the generated name of the DVT This will need further discussion. In the constant pool, references can use Qpackage.Class; rather than Lpackage.Class; Are there requirements for java sources to be able to refer to the derived value type by name? e.g. Class.forName()? If not, then perhaps the temporary naming convention could be kept internal? 9. Splitting the value type from the object type p.5 "The original class is given a new synthetic field of the new value type, to hold the state for the original class". - to simplify implementation, and allow experiments which go beyond the initial MVT plans, we propose * that the VCC is left untouched * the DVT has a copy of the immutable instance fields - We think this qualifies as "any equivalent technique" on p.5 - the quote above would need modifying or removing 10. Scoping of these features - exploring adding class file capability bits for experimental features, as a versioning approach - we will want to pin this down later in the cycle 11. JVM changes to support Q-types - "So when the class loader loads an object whose fields are Q_types, it must resolve (and perhaps load) the classes of those Q_types, ..." - for instance fields that are Q-types, I believe we need to explicitly specify temporary JVMS load/link/init rules (I will propose an early draft in a later email). - e.g. Specifically, for instance fields that are Q-types, we would propose requiring eager loading of the Q-types, modifying JVMS 5.3.5 Deriving a Class from a class File Representation. Bullets 3 and 4 described eager resolution of the direct superclass and direct superinterfaces. The expectation is that an additional bullet would be added for direct instance fields that are Q-types. - note that this change would make it the JVM's responsibility, not the class loaders' responsibility, to resolve the classes of those Q-types. Note: in the JVMS load/link/init rules I will also propose VCC/DVT load/link/init requirements. 12. value bytecodes - the following are useful in the MethodHandle implementation, and likely to be useful for direct bytecode access - we would like to propose the following as the minimal bytecode set: in addition to vload, vstore, vreturn (and slot-specific variants) - vdefault/vwithfield - vbox/vunbox - vaload/vastore - vgetfield (fetch a field from a value type) - NOT vcmp_eq/ne (equality can be implemented as component-wise comparison) clarify that for MVT 1.0, statics are only available through the box. (TODO: where does this go in shady?) 13. value bytecodes - open issue - typed prefix vs. vbytecodes for initial prototype 14. Value bytecodes use of Qtype as class component: "Initially the only valid use of a Q-type [is] as the class component of a CONSTANT_Methodref or CONSTANT_Fieldref is as a CONSTANT_MethodHandle constant." - if we extend the bytecodes as above, and we disallow anyone (MethodHandles, bytecodes) from invoking methods on Qtypes, we could modify this to disallow Q-types for CONSTANT_Methodref or CONSTANT_InterfaceMethodRef completely. - but perhaps you want the MethodHandles to be able to invoke methods on DVTs by dynamically boxing them. This works as long as the methods don't assume identity. 15. Q-types and bytecodes We propose modifying anewarray and multianewarray to allow operands that are Q-types. 16. Value Type Reflection With the proposed modifications in #8 above: i.e. leaving the VCC untouched and copying the instance fields to the DVT, the VCC now matches the source file. So Class.forName() would return the VCC which is the original POJO which fits the backward compatibility model. So we don't need a separate SourceClass, but leaving it in the proposal provides implementation flexibility. 17. Q-type method handles & behaviors "possible bytecode" might want to change vnew to vdefault these are samples and evolving, so maybe not worth changing I did not do this level of detailed review for the Future Work yet. thanks, Karen > On Sep 1, 2016, at 8:08 PM, John Rose wrote: > > On Aug 31, 2016, at 11:59 PM, John Rose wrote: >> >> I have updated of this document to reflect comments so far. >> It is stored to CR (in place) and enclosed here. >> ? John >> >> Link: http://cr.openjdk.java.net/~jrose/values/shady-values.html >> >> > > I have updated the document again with small corrections and clarifications. From karen.kinnear at oracle.com Thu Feb 9 23:31:02 2017 From: karen.kinnear at oracle.com (Karen Kinnear) Date: Thu, 9 Feb 2017 18:31:02 -0500 Subject: Initial feedback on Minimal Value Types 0.2 for discussion In-Reply-To: References: <2B1F10B9-45B6-466D-8D4B-A872DA0A01DB@oracle.com> Message-ID: <844A23A3-ECF3-44C4-90AD-E91372A4041C@oracle.com> Notes from discussion on Feb 01,2017. Feedback welcome. John - one question extracted at the top from the embedded notes. > 11. "interfaces (especially with default methods)" > - please change p.6 to clarify that there are no value type interfaces period. Ed note: There is a distinction here between 11a) defining an interface as a VCC with a derived DVT and 11b) whether the POJO which defines the VCC can implement interfaces. This discussion was about whether a POJO which defines the VCC can implement interfaces. John: MVT 1.0 : No value capable interfaces for JVMT 1.0. Ed note: was this the answer to 11a or 11b above please? > On Feb 9, 2017, at 5:43 PM, Karen Kinnear wrote: > > > (This is a resend of an email I sent to valhalla-dev at openjdk.java.net on January 23) > > Review of Minimal Value Types August 2016 Shady Edition (v 0.2) > http://cr.openjdk.java.net/~jrose/values/shady-values.html > > Questions/Comments: > abbreviations used: VCC: value-capable class, DVT: derived value type > > 1. Goals > -- might be worth adding to the bullets: > Allow use of existing toolchain where possible including IDEs and debuggers John: this is just a review comment, no discussion required. > > 2. Features: > "Three" bytecode instructions ->"A small set of? John: just a text edit to encompass extensions in #12 below, not yet discussed as a group. > > 3. Typically, value-capable classes will not be exported. > Is the reason for this to limit exposure since the expectation is that the > initial APIs and mechanisms will change? John: ?yes?. This does not have to be enforced in the implementation. ed. note: perhaps we could remove this from the MVT specification. > > 4. Value-capable classes: supporting methods > > p.3 "This design endows both boxes and pure values with a common set of methods; it "lifts" box methods > onto the derived values." > p.5 "The synthetic class has the given fields (unchanged) and has no methods" > p.5 "Meanwhile, all methods (and other class features) stay on the value-capable class. The value type > proper is just a "dumb struct" containing the extracted fields" > > - given that in the MVT model we are starting with a POJO box, and instance methods that clearly > take an Object as a receiver, one proposal for the initial MVT approach would be to have > all methods only supported by the box, and require boxing to invoke any methods > > - so I think the first quote would need either removal or modification John: agreed. Karen: See #9 below: Evolved proposal would keep the POJO, which we call the Value Capable Class (VCC) unchanged, and derive a Derived Value Type (DVT) which would only contain a copy of the immutable instance fields, i.e. be a ?dumb struct?. Bjorn: In this model, the source class would be the same as the box class, if we leave the instance fields in it. And we would box to invoke methods for the MVT 1.0 timeframe. John: Agreed. John: Longer-term - will want to invoke methods on values as soon as we can. We will need source support for that. John: Minimal Value Type (MVT) programming models: 1) source ? only works for boxes 2) Method Handle reflection - for early adopters 3) bytecodes The MethodHandle/ValueFactory approach is clearly described. The language and byte code we will use longterm are still uncertain. Bjorn: What would be enabled by having all members in the value vs. just the [instance] fields in the value? Karen: Challenge is instance methods, where the type of the receiver is expected to be a VCC, not a DVT. This same expectation applies to any method called from the instance method, or any field in which the receiver is stored. John: we are using existing javac support, therefore we need to define value types indirectly, box first. This is not the longterm plan. MethodHandles will provide a direct way of speaking of the values. The MethodHandle runtime will spin byte codes. Maurizio: it is easy to just map the fields Karen: Methods are coded on the box. Static fields we left on the box. So we just lift the instance fields. John: We box the value to run methods. We want to preserve ?vagueness?. Legacy code could misuse identity e.g. equals, hashcode, sync This only works for early adopters who are aware of value-capable-class identitylessness and implications Maurizio: If you pass the VCC to another method you are passing the box and no mechanical transformation is needed. Karen: You could have a problem if you were to pass the DVT as an argument when an object is expected John: clarify distinction between QType and LType QType: no identity, not nullable, not shared visible state, no sync, no reference equality LType: identity, nullable, shared visible state for sync and reference equality semantic mismatch: nulls, if_acmp_eq/ne MVT provides a short-term hack - which is ok for early adopters in future expect explicit boxes for QTypes which are LTypes which actually are identityful unlike the temporary VCCs Bjorn: differences between QTypes and LTypes like int and Integer, where only Integer provides methods? John: short-term there will be no methods on a DVT. longer-term value types will have methods verifier will not accept LType for a QType byte code Bjorn: if QType is a subset of an LType is it ok to convert? John: want ability farther future to have different behaviors and different stack representation. In progress, exploring possibly interpreter implementations, things like allowing the vm to buffer QTypes off the java heap presumes a universal type must declare whether it has identity or not Bjorn: with boxing and unboxing, if you say you have ?no identity? do you still have something? John: must box to call a method, no one can rely on the identity so you can elide it. Ed note: this is only possibly temporarily because the value-capable-class is defined as not being able to rely on identity. This will not carry over to a more general value type approach if we wish to have value types box to identityful LTypes which can be used by existing code that is expecting a subtype of Object or an Interface as defined today. John: after MVT 1.0, exploring a union type, ?UType? which is a common type that could contain either a QType or its corresponding LType > > 5. Value bytecodes > p.11 "Method handles and invokedynamic will always allow bytecode to invoke methods on Q-types". > - is this still accurate in the context above? I know the comment says that internally > the MH might box the Qtype, but do we still want to support MH and indy to appear to invoke methods on Q-types? Ed note: I don?t if we answered this question. > > 6. Restrictions on the POJO: > A. It would help to have a bulleted list of restrictions > B. Clarify error/exception to throw - perhaps ClassFormatError for all of these? > C. Request to not support VCC on interfaces at all for MVT 1.0 > > I know the restrictions are intermixed in the text today. This is what I extracted: > (p.3-4, 6) > > VCC (and probably going forward) > 1. VCC superclass must be Object (and should be omitted) > 2. the class must be final > 3. all fields must be final > - please clarify - all instance fields must be final John: yes > 4. all constructors private Maurizio: why? Note that there is NO constructor for the DVT. It can be created via a vunbox or vdefault + vwithfield John: ok to change the spec so the VCC constructor is not limited to being private. > 5. must replace equals, hashcode, toString (with current Object syntax) > 6. may not use any methods provided on Object > specifically: may not use clone, finalize, wait, notify, notifyAll (directly) > 7. may use getClass > MVT 1.0 additional limitations > 9. may contain primitive instance fields, but no reference instance fields > - please update document to clarify this restriction is for instance fields only Karen: both IBM and Oracle JVM engineers are interested in an optional extension to support references instance fields. Maurizio: If only primitives allowed, then no support for generics is needed. Clarification for Karen: statics can have generics with erasure today, but can not mention type variables. (thanks :-) Bjorn: With today?s erased generics, this is not a problem John: Ok to explore having references in instance fields, generics are ok. No type variables in instance fields and no ?any? generics. > 10. may not contain generic instance fields > - please update document to clarify this restriction is for instance fields only > - it is my understanding that you can?t have generic static fields at all > 11. "interfaces (especially with default methods)" > - please change p.6 to clarify that there are no value type interfaces period. Ed note: There is a distinction here between 11a) defining an interface as a VCC with a derived DVT and 11b) whether the POJO which defines the VCC can implement interfaces. This discussion was about whether a POJO which defines the VCC can implement interfaces. Karen: concern about setting expectations. Current interfaces assume identity. Maurizio: could always box to call interface methods. John: Question: do early adopters need interfaces? Vladimir Ivanov: Yes note: Vector API has no benefits using MVT 1.0. Ed note: later email clarification from Vlad: Interface-based Vector API version [1] does not benefit from MVT 1.0. All operations are expressed as interface calls and require vector boxes. That is out of scope for MVT 1.0. Vectors exploring an alternative API, exposing operations as MethodHandles. This is less convenient to use, but allows experimenting to find performance benefits. John: MVT: box to get to methods. Longterm get to call I.defaultmethod without boxing Ed. note: Interface default method will need restrictions. John: MVT 1.0 : No value capable interfaces for JVMT 1.0. Ed note: was this the answer to 11a or 11b above please? John: longer-term: L-Type: always identity Q- Type: never identity U-Type: do not assume identity, must preserve identity > 12. 0.2 version states: may not contain a value class as an instance field > - see below for further discussion > > 7. potential extensions: > 12. 0.2 version states: value class may not contain a value class as an instance field > - we would like to propose supporting this - perhaps as an optional extension? > - we would need to add an exception for handling circularity > - note: no way to express this in java, but you could express in a classfile John: NO for MVT 1.0. Potential ambiguity whether the field contains a value capable class or a derived value type javac just deals with boxes, so no flattening here. Wants same layouts whether boxed or not. John: MVT 1.0 will only flatten arrays reflectively End of discussion thanks, Karen ======= > > 8. Splitting the value type from the object type > Propose not using the nested class approach, to not tie us into this relationship longer term > - so remove example and the "looks like an inner class" > > - note: a key point here is how the user generating bytecodes would know the generated name of the DVT > This will need further discussion. > In the constant pool, references can use Qpackage.Class; rather than Lpackage.Class; > > Are there requirements for java sources to be able to refer to the derived value type by name? > e.g. Class.forName()? If not, then perhaps the temporary naming convention could be kept internal? > > 9. Splitting the value type from the object type > p.5 "The original class is given a new synthetic field of the new value type, to hold the state for the original class". > - to simplify implementation, and allow experiments which go beyond the initial MVT plans, we propose > * that the VCC is left untouched > * the DVT has a copy of the immutable instance fields > > - We think this qualifies as "any equivalent technique" on p.5 > - the quote above would need modifying or removing > > 10. Scoping of these features > - exploring adding class file capability bits for experimental features, as a versioning approach > - we will want to pin this down later in the cycle > > > 11. JVM changes to support Q-types > - "So when the class loader loads an object whose fields are Q_types, it must resolve (and perhaps load) > the classes of those Q_types, ..." > - for instance fields that are Q-types, I believe we need to explicitly specify temporary JVMS load/link/init rules > (I will propose an early draft in a later email). > - e.g. Specifically, for instance fields that are Q-types, we would propose requiring eager loading of the Q-types, > modifying JVMS 5.3.5 Deriving a Class from a class File Representation. Bullets 3 and 4 described eager resolution > of the direct superclass and direct superinterfaces. The expectation is that an additional bullet would be added > for direct instance fields that are Q-types. > - note that this change would make it the JVM's responsibility, not the class loaders' responsibility, > to resolve the classes of those Q-types. > > Note: in the JVMS load/link/init rules I will also propose VCC/DVT load/link/init requirements. > > 12. value bytecodes > - the following are useful in the MethodHandle implementation, and likely to be useful for direct bytecode access > - we would like to propose the following as the minimal bytecode set: > in addition to vload, vstore, vreturn (and slot-specific variants) > - vdefault/vwithfield > - vbox/vunbox > - vaload/vastore > - vgetfield (fetch a field from a value type) > - NOT vcmp_eq/ne (equality can be implemented as component-wise comparison) > > clarify that for MVT 1.0, statics are only available through the box. (TODO: where does this go in shady?) > > 13. value bytecodes > - open issue > - typed prefix vs. vbytecodes for initial prototype > > 14. Value bytecodes > use of Qtype as class component: > "Initially the only valid use of a Q-type [is] as the class component of a CONSTANT_Methodref or CONSTANT_Fieldref > is as a CONSTANT_MethodHandle constant." > - if we extend the bytecodes as above, and we disallow anyone (MethodHandles, bytecodes) from invoking methods on Qtypes, we > could modify this to disallow Q-types for CONSTANT_Methodref or CONSTANT_InterfaceMethodRef completely. > - but perhaps you want the MethodHandles to be able to invoke methods on DVTs by dynamically boxing them. This works as long > as the methods don't assume identity. > > 15. Q-types and bytecodes > We propose modifying anewarray and multianewarray to allow operands that are Q-types. > > 16. Value Type Reflection > With the proposed modifications in #8 above: i.e. leaving the VCC untouched and copying the > instance fields to the DVT, the VCC now matches the source file. > So Class.forName() would return the VCC which is the original POJO which fits the backward compatibility model. > So we don't need a separate SourceClass, but leaving it in the proposal provides implementation flexibility. > > 17. Q-type method handles & behaviors "possible bytecode" > might want to change vnew to vdefault > these are samples and evolving, so maybe not worth changing > > I did not do this level of detailed review for the Future Work yet. > > thanks, > Karen > >> On Sep 1, 2016, at 8:08 PM, John Rose > wrote: >> >> On Aug 31, 2016, at 11:59 PM, John Rose > wrote: >>> >>> I have updated of this document to reflect comments so far. >>> It is stored to CR (in place) and enclosed here. >>> ? John >>> >>> Link: http://cr.openjdk.java.net/~jrose/values/shady-values.html >>> >>> >> >> I have updated the document again with small corrections and clarifications. > From karen.kinnear at oracle.com Fri Feb 10 14:47:30 2017 From: karen.kinnear at oracle.com (Karen Kinnear) Date: Fri, 10 Feb 2017 09:47:30 -0500 Subject: Initial feedback on Minimal Value Types 0.2 for discussion In-Reply-To: References: <844A23A3-ECF3-44C4-90AD-E91372A4041C@oracle.com> <2B1F10B9-45B6-466D-8D4B-A872DA0A01DB@oracle.com> Message-ID: John - please correct Bjorn, Good question. This was news to us as well, so John will have the final word. My assumption is that he means that: If you create an array of Value-Capable-Classes that you would not automagically also create an equivalent array of the Derived Value Types. That the MethodHandle APIs could explicitly, through new byte codes create arrays of the DVTs by passing a Derived Value Type as the ?array ref? to anewarray or multianewarray. I presume that any explicit byte code generation by power users to go with this code could use the same mechanism. thanks, Karen > On Feb 9, 2017, at 10:56 PM, Bjorn B Vardal wrote: > > Karen / John: Can you clarify this? Do you mean that they will only be flattened when created using the reflection / MethodHandle API? > > > John: MVT 1.0 will only flatten arrays reflectively > > -- > Bj?rn V?rdal > J9 Java Virtual Machine Developer > IBM Runtimes > > > ----- Original message ----- > From: Karen Kinnear > Sent by: "valhalla-spec-experts" > To: John Rose > Cc: valhalla-spec-experts at openjdk.java.net > Subject: Re: Initial feedback on Minimal Value Types 0.2 for discussion > Date: Thu, Feb 9, 2017 6:31 PM > > Notes from discussion on Feb 01,2017. Feedback welcome. > > John - one question extracted at the top from the embedded notes. > >> 11. "interfaces (especially with default methods)" >> - please change p.6 to clarify that there are no value type interfaces period. > Ed note: There is a distinction here between > 11a) defining an interface as a VCC with a derived DVT and > 11b) whether the POJO which defines the VCC can implement interfaces. This discussion was about whether > a POJO which defines the VCC can implement interfaces. > John: MVT 1.0 : No value capable interfaces for JVMT 1.0. > Ed note: was this the answer to 11a or 11b above please? >> On Feb 9, 2017, at 5:43 PM, Karen Kinnear > wrote: >> >> >> (This is a resend of an email I sent to valhalla-dev at openjdk.java.net on January 23) >> >> Review of Minimal Value Types August 2016 Shady Edition (v 0.2) >> http://cr.openjdk.java.net/~jrose/values/shady-values.html >> >> Questions/Comments: >> abbreviations used: VCC: value-capable class, DVT: derived value type >> >> 1. Goals >> -- might be worth adding to the bullets: >> Allow use of existing toolchain where possible including IDEs and debuggers > John: this is just a review comment, no discussion required. >> >> >> 2. Features: >> "Three" bytecode instructions ->"A small set of? > John: just a text edit to encompass extensions in #12 below, not yet discussed as a group. >> >> >> 3. Typically, value-capable classes will not be exported. >> Is the reason for this to limit exposure since the expectation is that the >> initial APIs and mechanisms will change? > John: ?yes?. This does not have to be enforced in the implementation. > ed. note: perhaps we could remove this from the MVT specification. >> >> >> 4. Value-capable classes: supporting methods >> >> p.3 "This design endows both boxes and pure values with a common set of methods; it "lifts" box methods >> onto the derived values." >> p.5 "The synthetic class has the given fields (unchanged) and has no methods" >> p.5 "Meanwhile, all methods (and other class features) stay on the value-capable class. The value type >> proper is just a "dumb struct" containing the extracted fields" >> >> - given that in the MVT model we are starting with a POJO box, and instance methods that clearly >> take an Object as a receiver, one proposal for the initial MVT approach would be to have >> all methods only supported by the box, and require boxing to invoke any methods >> >> - so I think the first quote would need either removal or modification > John: agreed. > Karen: See #9 below: Evolved proposal would keep the POJO, which we call the Value Capable Class (VCC) unchanged, > and derive a Derived Value Type (DVT) which would only contain a copy of the immutable instance fields, i.e. be > a ?dumb struct?. > Bjorn: In this model, the source class would be the same as the box class, if we leave the instance fields in it. And we > would box to invoke methods for the MVT 1.0 timeframe. > John: Agreed. > John: Longer-term - will want to invoke methods on values as soon as we can. We will need source support for that. > > John: Minimal Value Type (MVT) programming models: > 1) source ? only works for boxes > 2) Method Handle reflection - for early adopters > 3) bytecodes > The MethodHandle/ValueFactory approach is clearly described. > The language and byte code we will use longterm are still uncertain. > Bjorn: What would be enabled by having all members in the value vs. just the [instance] fields in the value? > Karen: Challenge is instance methods, where the type of the receiver is expected to be a VCC, not a DVT. This same > expectation applies to any method called from the instance method, or any field in which the receiver is stored. > John: we are using existing javac support, therefore we need to define value types indirectly, box first. This is not the longterm plan. > MethodHandles will provide a direct way of speaking of the values. The MethodHandle runtime will spin byte codes. > > Maurizio: it is easy to just map the fields > Karen: Methods are coded on the box. Static fields we left on the box. So we just lift the instance fields. > > John: We box the value to run methods. We want to preserve ?vagueness?. > Legacy code could misuse identity e.g. equals, hashcode, sync > This only works for early adopters who are aware of value-capable-class identitylessness and implications > > Maurizio: If you pass the VCC to another method you are passing the box and no mechanical transformation is needed. > Karen: You could have a problem if you were to pass the DVT as an argument when an object is expected > John: clarify distinction between QType and LType > QType: no identity, not nullable, not shared visible state, no sync, no reference equality > LType: identity, nullable, shared visible state for sync and reference equality > semantic mismatch: nulls, if_acmp_eq/ne > MVT provides a short-term hack - which is ok for early adopters > in future expect explicit boxes for QTypes which are LTypes which actually are identityful unlike the temporary VCCs > Bjorn: differences between QTypes and LTypes like int and Integer, where only Integer provides methods? > John: short-term there will be no methods on a DVT. > longer-term value types will have methods > verifier will not accept LType for a QType byte code > Bjorn: if QType is a subset of an LType is it ok to convert? > John: want ability farther future to have different behaviors and different stack representation. > In progress, exploring possibly interpreter implementations, things like allowing the vm to buffer QTypes off the java heap > presumes a universal type must declare whether it has identity or not > Bjorn: with boxing and unboxing, if you say you have ?no identity? do you still have something? > John: must box to call a method, no one can rely on the identity so you can elide it. > Ed note: this is only possibly temporarily because the value-capable-class is defined as not being able to rely on identity. > This will not carry over to a more general value type approach if we wish to have value types box to identityful LTypes which > can be used by existing code that is expecting a subtype of Object or an Interface as defined today. > John: after MVT 1.0, exploring a union type, ?UType? which is a common type that could contain either a QType or its corresponding > LType >> >> 5. Value bytecodes >> p.11 "Method handles and invokedynamic will always allow bytecode to invoke methods on Q-types". >> - is this still accurate in the context above? I know the comment says that internally >> the MH might box the Qtype, but do we still want to support MH and indy to appear to invoke methods on Q-types? > Ed note: I don?t if we answered this question. >> >> >> 6. Restrictions on the POJO: >> A. It would help to have a bulleted list of restrictions >> B. Clarify error/exception to throw - perhaps ClassFormatError for all of these? >> C. Request to not support VCC on interfaces at all for MVT 1.0 >> >> I know the restrictions are intermixed in the text today. This is what I extracted: >> (p.3-4, 6) >> >> VCC (and probably going forward) >> 1. VCC superclass must be Object (and should be omitted) >> 2. the class must be final >> 3. all fields must be final >> - please clarify - all instance fields must be final > John: yes >> >> 4. all constructors private > Maurizio: why? > Note that there is NO constructor for the DVT. It can be created via a vunbox or vdefault + vwithfield > John: ok to change the spec so the VCC constructor is not limited to being private. >> >> 5. must replace equals, hashcode, toString (with current Object syntax) >> 6. may not use any methods provided on Object >> specifically: may not use clone, finalize, wait, notify, notifyAll (directly) >> 7. may use getClass >> MVT 1.0 additional limitations >> 9. may contain primitive instance fields, but no reference instance fields >> - please update document to clarify this restriction is for instance fields only > Karen: both IBM and Oracle JVM engineers are interested in an optional extension to support > references instance fields. > Maurizio: If only primitives allowed, then no support for generics is needed. > Clarification for Karen: statics can have generics with erasure today, but can not mention type variables. (thanks :-) > Bjorn: With today?s erased generics, this is not a problem > John: Ok to explore having references in instance fields, generics are ok. No type variables in instance fields > and no ?any? generics. > >> >> 10. may not contain generic instance fields >> - please update document to clarify this restriction is for instance fields only >> - it is my understanding that you can?t have generic static fields at all >> 11. "interfaces (especially with default methods)" >> - please change p.6 to clarify that there are no value type interfaces period. > Ed note: There is a distinction here between > 11a) defining an interface as a VCC with a derived DVT and > 11b) whether the POJO which defines the VCC can implement interfaces. This discussion was about whether > a POJO which defines the VCC can implement interfaces. > > Karen: concern about setting expectations. Current interfaces assume identity. > Maurizio: could always box to call interface methods. > > John: Question: do early adopters need interfaces? > Vladimir Ivanov: Yes > > note: Vector API has no benefits using MVT 1.0. > Ed note: later email clarification from Vlad: > Interface-based Vector API version [1] does not benefit from MVT 1.0. All operations are expressed as interface > calls and require vector boxes. > That is out of scope for MVT 1.0. > Vectors exploring an alternative API, exposing operations as MethodHandles. This is less convenient to use, but > allows experimenting to find performance benefits. > > John: MVT: box to get to methods. Longterm get to call I.defaultmethod without boxing > Ed. note: Interface default method will need restrictions. > > John: MVT 1.0 : No value capable interfaces for JVMT 1.0. > Ed note: was this the answer to 11a or 11b above please? > > John: longer-term: > L-Type: always identity > Q- Type: never identity > U-Type: do not assume identity, must preserve identity > >> >> 12. 0.2 version states: may not contain a value class as an instance field >> - see below for further discussion >> >> 7. potential extensions: >> 12. 0.2 version states: value class may not contain a value class as an instance field >> - we would like to propose supporting this - perhaps as an optional extension? >> - we would need to add an exception for handling circularity >> - note: no way to express this in java, but you could express in a classfile > John: NO for MVT 1.0. Potential ambiguity whether the field contains a value capable class or a derived value type > javac just deals with boxes, so no flattening here. Wants same layouts whether boxed or not. > > John: MVT 1.0 will only flatten arrays reflectively > > End of discussion > > thanks, > Karen > ======= > >> >> 8. Splitting the value type from the object type >> Propose not using the nested class approach, to not tie us into this relationship longer term >> - so remove example and the "looks like an inner class" >> >> - note: a key point here is how the user generating bytecodes would know the generated name of the DVT >> This will need further discussion. >> In the constant pool, references can use Qpackage.Class; rather than Lpackage.Class; >> >> Are there requirements for java sources to be able to refer to the derived value type by name? >> e.g. Class.forName()? If not, then perhaps the temporary naming convention could be kept internal? >> >> 9. Splitting the value type from the object type >> p.5 "The original class is given a new synthetic field of the new value type, to hold the state for the original class". >> - to simplify implementation, and allow experiments which go beyond the initial MVT plans, we propose >> * that the VCC is left untouched >> * the DVT has a copy of the immutable instance fields >> >> - We think this qualifies as "any equivalent technique" on p.5 >> - the quote above would need modifying or removing >> >> 10. Scoping of these features >> - exploring adding class file capability bits for experimental features, as a versioning approach >> - we will want to pin this down later in the cycle >> >> >> 11. JVM changes to support Q-types >> - "So when the class loader loads an object whose fields are Q_types, it must resolve (and perhaps load) >> the classes of those Q_types, ..." >> - for instance fields that are Q-types, I believe we need to explicitly specify temporary JVMS load/link/init rules >> (I will propose an early draft in a later email). >> - e.g. Specifically, for instance fields that are Q-types, we would propose requiring eager loading of the Q-types, >> modifying JVMS 5.3.5 Deriving a Class from a class File Representation. Bullets 3 and 4 described eager resolution >> of the direct superclass and direct superinterfaces. The expectation is that an additional bullet would be added >> for direct instance fields that are Q-types. >> - note that this change would make it the JVM's responsibility, not the class loaders' responsibility, >> to resolve the classes of those Q-types. >> >> Note: in the JVMS load/link/init rules I will also propose VCC/DVT load/link/init requirements. >> >> 12. value bytecodes >> - the following are useful in the MethodHandle implementation, and likely to be useful for direct bytecode access >> - we would like to propose the following as the minimal bytecode set: >> in addition to vload, vstore, vreturn (and slot-specific variants) >> - vdefault/vwithfield >> - vbox/vunbox >> - vaload/vastore >> - vgetfield (fetch a field from a value type) >> - NOT vcmp_eq/ne (equality can be implemented as component-wise comparison) >> >> clarify that for MVT 1.0, statics are only available through the box. (TODO: where does this go in shady?) >> >> 13. value bytecodes >> - open issue >> - typed prefix vs. vbytecodes for initial prototype >> >> 14. Value bytecodes >> use of Qtype as class component: >> "Initially the only valid use of a Q-type [is] as the class component of a CONSTANT_Methodref or CONSTANT_Fieldref >> is as a CONSTANT_MethodHandle constant." >> - if we extend the bytecodes as above, and we disallow anyone (MethodHandles, bytecodes) from invoking methods on Qtypes, we >> could modify this to disallow Q-types for CONSTANT_Methodref or CONSTANT_InterfaceMethodRef completely. >> - but perhaps you want the MethodHandles to be able to invoke methods on DVTs by dynamically boxing them. This works as long >> as the methods don't assume identity. >> >> 15. Q-types and bytecodes >> We propose modifying anewarray and multianewarray to allow operands that are Q-types. >> >> 16. Value Type Reflection >> With the proposed modifications in #8 above: i.e. leaving the VCC untouched and copying the >> instance fields to the DVT, the VCC now matches the source file. >> So Class.forName() would return the VCC which is the original POJO which fits the backward compatibility model. >> So we don't need a separate SourceClass, but leaving it in the proposal provides implementation flexibility. >> >> 17. Q-type method handles & behaviors "possible bytecode" >> might want to change vnew to vdefault >> these are samples and evolving, so maybe not worth changing >> >> I did not do this level of detailed review for the Future Work yet. >> >> thanks, >> Karen >> >>> On Sep 1, 2016, at 8:08 PM, John Rose > wrote: >>> >>> On Aug 31, 2016, at 11:59 PM, John Rose > wrote: >>>> >>>> >>>> I have updated of this document to reflect comments so far. >>>> It is stored to CR (in place) and enclosed here. >>>> ? John >>>> >>>> Link: http://cr.openjdk.java.net/~jrose/values/shady-values.html >>>> >>>> >>> >>> I have updated the document again with small corrections and clarifications. > > >