minutes Valhalla EG June 07, 2017

Wed Jun 21 14:19:32 UTC 2017

Dan - 

I can’t find it either. We’ll have to ask John.

thanks,
Karen

> On Jun 21, 2017, at 9:55 AM, Daniel Heidinga <Daniel_Heidinga at ca.ibm.com> wrote:
> 
> >  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.kinnear at oracle.com>
> Sent by: "valhalla-spec-experts" <valhalla-spec-experts-bounces at openjdk.java.net>
> To: valhalla-spec-experts at 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
>  
>  
>  
> 