minutes Valhalla EG June 07, 2017

[Karen Kinnear]

Valhalla EG Minutes June 07, 2017

attendees: Bjorn, Dan H, Dan S, John, Vlad, Frederic, Lois, Brian, Maurizio, Karen

AI ALL:
  Dan Smith sent an initial draft of a JVMS with experimental support for MVT for review.
  Feedback in email requested - sooner rather than later please.
AI ALL:
  Review embedded proposal for issue 1 - John javadoc to avoid exposing internal derived value type name
  Review embedded proposal for EA for handling CONSTANT_Class

Timing note:
  Value type exploration is following three timeframes:
     Minimal Value Types Early Access (EA) - goal: ASAP so we can get feedback from initial users
     Minimal Value Types (MVT)   - goal: w/JDK10 for much broader feedback
     Valhalla Value Types - "real" vs. shady values - much richer feature set
  Some of the issues we are exploring - such as type vs. class will need to evolve, so we need
  to reach decisions on our initial EA stake in the ground ASAP.
  For that - review of and conclusions to JVMS and other open issues is needed.

Issue 1: Exposure of mirror and mirror name for the value class
Bjorn: (please correct any inaccuracies)
  IBM implementation does NOT expose the value type mirror name
  ValueType.valueClass is the only way to get the value type mirror
  getClassName returns the same answer
  2 java objects, same underlying data
  no internal derived value type name is exposed

John: proposal for breaking the link to the secondary mirror
   Model is that there is one primary mirror and multiple secondary mirrors
   Brian: one nominal class and multiple derived classes analogous to a DirectMethodHandle and derived
MethodHandles
   Later reflection couild add APIs at the java level to get the secondary mirrors
   - has an initial proposal in which you pass in
       head class, user data (e.g. value type descriptor), user-chosen name
       name is not resolvable, doesn't work for findClass, but visible when reflecting

Dan H: do we need to ensure user name/user data consistent? That has been an issue in related APIs?
John: no
Karen: assume we can not use this name to look up a class (forName)? just for reflection to print?
John: not for lookup

Maurizio: this could be useful today (i.e. for EA) for a value class
Issue: Reflection behavior for EA
   Karen: we already agreed reflection will not work - will throw an exception
   Maurizio: it could be actually easier to use John's factory than to throw an exception

Timing:
  AI: John - send out javadoc to EG
derived class := Class.derivedClassFactory(Class mainClass, T userData, String name)
  All: evaluate proposal both for doability
       also evaluate for timing: EA vs. MVT?


Issue 2: Constant Pool representation for derived value type (JVMS term: value class)

Goals:
  1. cache point for usage - need separate storage for DVT and VCC
  2. prefer not to do string parsing over and over to get the mode
  3. verifier ensure type safety without additional eager class loading
  4. ensure single resolution of underlying value-capable-class
     (longer-term want single resolution of underlying source classfile)
  5. allow implementations to support older classfiles
  6. tool support - make sure this works for a mix of constant pool changes
     e.g. tools that do not know about new versions still instrument new classfiles
     - need to make sure these still work as much as possible
     - so for these folks we need to not change the meaning of CONSTANT_Class
  7. future - make sure the model works for future derivation from more than one type
     - e.g. Foo<Bar>
    7a. request that for a Parameterized Type: this_class (name and CONSTANT_Class today)
        allows lazy resolution of the list
    (ed. note: need to discuss details of "lazy" here - loading the class file perhaps,
    but instantiating a type from it will need the parameterizations, so far we have
    conceptually recorded the loaded class file under the "head" type, with default/erased
    parameterizations)
  8. upside opportunity: Constable and pattern matching - helpful if all class objects
     were represented the same way when generating bytecode
     e.g. int.class vs. Integer.class require different handling today
  9. migration: a class should be able to migrate to being a value type
     approach: will require boxing to access, but if you pass for example a boxed value type
     the current client should continue to work
  10. migration: value type to reference?  Open question

   11. ed. note: we did not mention that for MVT we actually have multiple source classfiles and
   at least one potential prototype for parameterized types also generates separate classfiles.
   While we strongly do not want to build in the concept of multiple separate classfiles, it
   would be valuable if the constant pool representation was able to support that.
   This might help extend to nested classes as well.

John:

two views of CONSTANT_Class:
   1. is it a type? then need nested CONSTANT_ClassFile: Class[ClassFile]
   2.  is it a loaded class file?  then need surrounding decoration Type[Class]
bad third choice:  3. use separately resolved peers Class["name.1"], Class["name.2"]  where name is mangled but
refers to same loaded class file

Today: CONSTANT_Class represents both the type and the loaded class file.

Dan S:
  Prefers option 1: type with a reference to a raw classfile
(ed. note - Dan S - I didn't get any details on why you prefer this for longer-term, it would help
to understand)
(ed. note - Dan S - can you add some notes on how to represent goal #11?)

Bjorn:
  Are there any cases in which a classfile does not represent a reference type?
  Valhalla - goal is that the classfile represents both value type and the boxed value type

Proposal from John/Karen:
  CONSTANT_Class_info: used for both the "head" LType and the classfile - conflate for backward compatibility
  CONSTANT_Value_info: mode information and references the underlying CONSTANT_Class_info
  Parameterized type: has auxiliary info and references at least on underlying (head) CONSTANT_Class_info
     e.g. List<Foo> would reference List class, and Foo would linked to in auxiliary info

AI: All
  Explore this potential model:
  Would this make sense from a JVMS perspective?
  Would this work for JVM implementations?
  Would this work for bytecode generation etc?
  - please check if this is feasible short-term, i.e. for EA
  - also explore if we could "flop" to #1 later

Feedback:
John: short term: Try the proposal above with CONSTANT_Value_info refering to an underlying CONSTANT_Class_info
  Spec direction is likely to be CONSTANT_Class references a Classfile
Lois: ok with verifier
Frederic: ok with bytecodes
Bjorn: prefer #3 ;Q - for MVT - it has minimal impact
   ok with #2, but the change wouldn't slow us down much
Frederic: todwy - handle by using separate opcodes and all have CONSTANT_Class
(ed. note - and we haven't implemented the verifier which would like to sanity check
that the CONSTANT_Class matches the expected type in the opcode)


---
3. Ways to phase out current classfile capabilities such as CONSTANT_Class? Or LDC CONSTANT_Class?
Brian: jigsaw added the (not so popular) concept of runtime warnings
Maurizio - jsr/ret deprecated (John: ACC_SUPER) - not used much - javac was primary client at the time
   StackMapTable added - lots of complaints

What if long-term we were to derive arrays using multi-level constant pool entries
What if we were to support Q[ as well as L arrays?
   - immutable, non-nullable, identityless

John: What if we were to evolve CONSTNAT_MethodType - currently a flat string to use tree structured approach?

Dan H: limited numbers of places we parse descriptors
Karen: don't slow down our resolution method and field lookup
Dan H: limited to resolution time
Dan S: might be faster to look up using tree comparison vs. extra long symbols
ed. note: worth exploring - just be really sure there is no potential for ambiguity,
        i.e. at any resolution step: do you have a match for X or Y

---
4. Box and value implementation relationships
  goal: reduce costs when boxing/unboxing
    -e.g. same layout alignment for fields
    - what if we could just change 1 bit in the carrier

---
5. Opcode proposal:
drop vgetfield, overload getfield instead
Bjorn: concern - not want performance impact on existing opcodes
John: propose discard the extra defined opcode and leave room for quickening

overload: anewarray, multianewarray

Chat room notes on details:
John:
uses of C_Class as a class-file: this_class, PType head-type (template) uses of C_Class as a type:  ldc,
?Field/Methodref?
Dan S:
Arbitrary types allowed: anewarray, multianewarray, structural descriptor, ldc, bootstrap argument,
verification_type_info, maybe field/method refs
Reference types allowed: checkcast, instanceofReference
class/species allowed: super_class, interfaces, new, annotation, catch_type, Exceptions
Plain class required: this_class, InnerClasses, EnclosingMethod, maybe field/method refs
Maurizio:
was thinking the recently that InnerClasses is probably another 'classfile' use
John:
Agree
ldc is not arbitrary type, b/c ldc int.class not possible; ldc is L-type only