Valhalla Minimal Value Types review invitation

Tue Apr 11 22:38:52 UTC 2017

Summary of requested modifications from early prototyping experiments. Followed by action items.

Terms used below: VCC for Value Capable Class annotated for creating a DVT: Derived Value
This is to distinguish from the longer-term VVT, or Valhalla Value Type that will be supported
by javac and have more capabilities, such as supporting interfaces and methods.

1. Features:
   Could you possibly introduce the term "Derived Value Type" for the unboxed form of a Value-capable-class?

2. Features:
   "Three" bytecode instructions ->"A small set of"

3. Value-capable classes
   annotation restrictions: (The details are TBD, but will be similar to the restrictions on internal
   annotations like @Contended or @PolymorphicSignature.)

   For early access, don't restrict the annotation. Option via command-line switch

4. Remove this entirely:
"(Until there are bytecodes for directly accessing members of unboxed values, method handles will be
  available for the purpose, as they are for members of regular objects. This design endows both boxes
  and pure values with a common set of methods; it lifts box methods onto the derived values. The reasons
  for doing this, in the prototype system, are noted below. This somewhat awkward, backward setup is
  the necessary initial scaffolding, not the final edifice.)"

-- we have simplified the implementation by removing methods from the DVT completely
-- we have proposed adding new bytecodes for directly accessing members of DVTs
   vgetfield - access a field of a value type and
   vwithfield - "wither" - to create a new value type copy-on-write

5. Clarify:
   DVT will just contain the instance fields.
   VCC will remain unchanged.
   To invoke a method or access a static field, must box to VCC.
   Identity for both the VCC and DVT is "accidental”.

6. Restrictions on the POJO:
A. It would help to have a bulleted list of restrictions, including error to throw

   I know the restrictions are intermixed in the text today. This is what I extracted:
   (p.3-4, 6)

VCC
   1. VCC superclass must be Object (and should be omitted)
   2. May not inherit from any interfaces
   3. the class must be final
   4. all instance fields must be final
   5. an Interface can not be marked with @DeriveValueType
      please change p.6 "interfaces (especially with default methods)" to clarify that there are
      no value type interfaces period.

   6. must replace equals, hashcode, toString (with current Object syntax)
   7. may not use any methods provided on Object
      specifically: may not use clone, finalize, wait, notify, notifyAll (directly)
   8. May not inherit from any interfaces
   9. may use getClass

Remove Restrictions:
   1. all constructors private *** remove this restriction ***
      Note: the DVT does not have a constructor - it can be created via a vunbox or a vdefault + vwithfield
      or as a side effect of newarray/multianewarray of a DVT
   2. may contain primitive instance fields, but no reference instance fields
       *** requested extension by IBM and Oracle: please remove this restriction
   3. may not contain generic instance fields
       *** erased generics are ok. No type variables in instance fields and no "any” generics

7. Continue with "value class may not contain a value class as an instance field".
   Value classes contained in references will not be flattened.

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"
  - leave this as an implementation detail, but do NOT expose DVT as a nested class

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.  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)

11. clarify that for MVT 1.0, statics are only available through the box. (TODO: where does this go in shady?)

12. vdefault/vwithfield
    restrictions: vdefault only within constructor, vwithfield only within the class
     note: temporary issue: since DVT has no constructor or other methods, must allow 
     vdefault also within the DVT and vwithfield across VCC/DVT pairs.
     note: a value type array allows default value to escape

13. value bytecodes
    vbytecodes for early access (not typed bytecodes for early access)

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 as the class component for CONSTANT_Methodref or CONSTANT_InterfaceMethodRef completely.

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 #5 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. splitting the value type from the VCC - name of the derived value type
   Decided that MVT 1.0 should clarify that we do not want reflection or bytecodes to resolve a temporary name to
   find a DVT.
   Users can use ValueType.valueClass() to get the class  or vunbox or QVCCNAME in a descriptor (i.e. not the temporary name)
   - so the internal naming does not have to be specified or known.

18. Reflection:
   There is no contract in MVT for the DVT to support reflection. It is ok to throw an exception - need to
investigate what is easiest here. Core reflection works on the VCC, so box to use it.

19. When we update to supporting VVT there is no guarantee that MVT classes will continue to work.
This is experimental, the classfile format is experimental, the byte codes are temporary.

20. Vdefault/vwithfield: need to study relative to verification rules to ensure no escape of partially constructed

AIs:
1. Comparison of PackedObjects vs. Minimal Value Types: Dan Heidinga/Bjorn Vandal
2. Request for JVMS extensions draft: Dan Smith will be at the April 26th meeting
3. MVT JEP: John
4. MVT update based on feedback: John
5. JEP for how to do experimental JVMS/JVM features: ??
   - e.g. command-line flag vs. classfile version?

Additional questions:
MethodHandle support: Want a way to have MH.Lookup operate on a DVT as if it had methods. Possibly
by doing the Lookup on the VCC and doing an asType conversion. Also want a way for MH.arraygetter/arraysetter
to pass a DVT.

Additional questions welcome.

thanks,
Karen

> On Mar 30, 2017, at 12:35 PM, Karen Kinnear <karen.kinnear at oracle.com> wrote:
> 
> Those interested in the Valhalla Minimal Value Types early adopters proposal are invited
> to give feedback on John Rose’s 0.2 version:
> http://cr.openjdk.java.net/~jrose/values/shady-values.html
> 
> The goal is to make an early subset of value type behaviors available for experimentation.
> Email feedback is welcome.
> 
> In addition, you may join us for interactive discussions:
> 
> Biweekly starting Wednesday April 12th, 9am PT
> 
> URL to join the Oracle Zoom Conference: https://oracle.zoom.us/j/608512921?pwd=tVeSnAlOQYI%3D
> 
> audio only:     +1 646 558 8656 or +1 408 638 0968 US Toll
>                       Meeting ID: 608 512 921
> 
> My sincere apologies for missing you on the original invitation which we issued to IBM so
> that we could have a JVM implementors' discussion on questions about the Minimal Value Types
> proposal.
> 
> I will send a follow-up email with a summary of the requested modifications so far from the prototyping
> experiments.
> 
> thanks,
> Karen
> 
> 
> 
> 
> 
> 