Re: minutes Valhalla EG June 07, 2017

[Daniel Heidinga]

>  AI: John - send out javadoc to EG
> derived class := Class.derivedClassFactory(Class mainClass, T userData, String name)

 

In the spirit of the usual "5 min before the meeting" ritual action item panic, I'm trying to review the javadoc for this and can't seem to find it.  Can it be sent again?

 

Thanks,

--Dan

 

----- Original message -----
From: Karen Kinnear <karen.kinn...@oracle.com>
Sent by: "valhalla-spec-experts" <valhalla-spec-experts-boun...@openjdk.java.net>
To: valhalla-spec-experts@openjdk.java.net
Cc:
Subject: minutes Valhalla EG June 07, 2017
Date: Wed, Jun 7, 2017 4:28 PM
 

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