Initial feedback on Minimal Value Types 0.2 for discussion

[Karen Kinnear]

(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 <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 <john.r.rose at oracle.com> wrote:
> 
> On Aug 31, 2016, at 11:59 PM, John Rose <john.r.rose at oracle.com> 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
>> 
>> <shady-values.html>
> 
> I have updated the document again with small corrections and clarifications.

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.openjdk.java.net/pipermail/valhalla-spec-experts/attachments/20170209/77539f3e/attachment-0001.html>