Valhalla EG minutes 6/21/17

Wed Jul 5 14:12:30 UTC 2017

Bjorn,

Thank you for the corrections.
> On Jul 5, 2017, at 5:10 AM, Bjorn B Vardal <bjornvar at ca.ibm.com> wrote:
> 
> > Bjorn: single representation for both value capable class and derived value class
>  
> We basically rely on single class data structure for the VCC and DVT, but we still expose these as separate java/lang/Class objects.
>  
>  
> >     I think you said “treat ;Q” as the name for the derived value class rather than as an escape character  (feel free to correct my notes)
>  
> I meant to say the opposite of that: Since our DVT and VCC have the same name (because they rely on the same class data structure),
> we would simply treat ";Q" as an escape character that switches to DVT mode, instead of as part of the name of the value class.
That makes more sense.
>  
>  
> > Bjorn: could hack using the different name as two views of the same thing
> >    e.g. vbox/vunbox would need to swap names
> >    (ed. note - please let us know if this is doable without heroic efforts)
>  
> I can make this work as long as there's a predictable prefix and suffix, so ";Q<name>$value" works.
Thank you - very much appreciated.
>  
>  
> > Dan S: class loading in the proposed JVMS: if you see $Value
> >    1) first derive the VCC name and see if already resolved
> >    2) if not - load the VCC, check properties and derive
> >    (ed. note - if see VCC - lazily derive derived value class on touch)
>  
> It's not a requirement that the value class derivation is lazy, correct?

Let’s double-check with Dan Smith at today’s meeting.

The way I read 5.3 Creation and Loading in
http://cr.openjdk.java.net/~dlsmith/values.html
it appears to allow lazy derivation as well as eager derivation, which I think is what we both want
since it allows implementations to optimize.
Our current derivation is also eager.

thanks,
Karen

>  
>  
>  
> ----- 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: Valhalla EG minutes 6/21/17
> Date: Fri, Jun 23, 2017 10:33 PM
>  
> attendees: Remi, Bjorn, Dan H, Dan S, John, Maurizio, Frederic, Lois, Karen
>  
> AIs:
> All: review Dan Smith’s proposals
>    MVT JVMS: Specification for Value Classes: http://cr.openjdk.java.net/~dlsmith/values.html <http://cr.openjdk.java.net/~dlsmith/values.html> - initial proposal
> *** let’s pin this down ASAP so we - Remi for ASM, IBM and Oracle can deliver early binaries for early adopters to try
>  
>    incremental proposals for post early access (or maybe post - MVT TBD)
>        Direct Value Class: Specification for Value Classes with Explicit Declarations: http://cr.openjdk.java.net/~dlsmith/values-declaration.html <http://cr.openjdk.java.net/~dlsmith/values-declaration.html>
>        Specification for Value Classes with CONSTANT_ClassType: http://cr.openjdk.java.net/~dlsmith/values-classtype.html#values-classtype-4.1 <http://cr.openjdk.java.net/~dlsmith/values-classtype.html#values-classtype-4.1>
> All: review John Rose’s proposals:
>       ConstantDynamic JVMS changes: http://cr.openjdk.java.net/~jrose/jvm/condy-jvms-2017-0620.html <http://cr.openjdk.java.net/~jrose/jvm/condy-jvms-2017-0620.html>
> note: this is orthogonal to MVT
>       java/lang/Class.java makeSecondaryClass: http://mail.openjdk.java.net/pipermail/valhalla-spec-experts/2017-June/000286.html <http://mail.openjdk.java.net/pipermail/valhalla-spec-experts/2017-June/000286.html>
>                 post EA
>  
> Hotspot and IBM:
>   what could be available for early access  for early adopters to experiment with?
>   revisit early access timing - if we were to set expectations that
>      - model would be to deliver binaries and periodic binary updates to match the source builds. This is not a one shot delivery.
>      - limit functionality (platforms, reflection behavior unspecified, no JVMTI, …)
>      - performance improvements are not yet there, expect to come in incrementally
>      - maybe verifier isn’t ready?
>      - stability issues
>  
> Potential early adopters: Ian Graves? Doug Lea? Others?
>     So - would you be willing to start experimenting with minimal value types even with the restrictions above?
>  
>     We would find it helpful to get your feedback on
>        - the basic conceptual model
>        - usage model
>        - use cases - so we can optimize what you care about
>        - required features we missed 
>     - so that when we ship this experimentally it is much closer to what you need
>  
> Model of usage:
> 1) Value-capable-class: created in java with annotation, javac generates a regular classfile with no new constant pool entries
> or bytecodes
> 2) MethodHandles and ValueType APIs
>      - this is the default model of usage
> 3) generated byte codes
>     - you can generate your own byte codes to work on value types
>     - at this point you can’t generate your own value type class this way (until we get to Direct Value Class support)
>  
> Constant Pool changes for Early Access:
> 1) proposal for a value class is:
>       part I: CONSTANT_Class_info: UTF8: “;Q<name>;” // i.e. this would be a descriptor using a UTF8 string to speed up implementation
>       part II: hotspot requests that we use a different name for the value type than for the value capable class
>            implementation request - today we need unique strings to identify unique runtime types and this is baked in multiple places
>  
>      So propose: CONSTANT_Class_info: UTF8:”QFoo$
>  
> Where is the name exposed?
>    in the constant pool when you generate your own bytecodes - in descriptors and class names
>  
> Dan S: Longer term: will declare a value class directly. The box first is a temporary approach in which we derive the value class.
> Propose we not spend a lot of time here blurring the difference and needing to hide the derived value class.
>  
> Bjorn: single representation for both value capable class and derived value class
>     I think you said “treat ;Q” as the name for the derived value class rather than as an escape character  (feel free to correct my notes)
>    
> Dan S. Longer term: we do want one declaration and two views based on the value class.
>  
> John: prefers Bjorn’s approach
>  
> Bjorn: could hack using the different name as two views of the same thing
>    e.g. vbox/vunbox would need to swap names
>    (ed. note - please let us know if this is doable without heroic efforts)
>  
> John: for hotspot - part of condy refactoring did part of the loaded class cache lookup changes that could be used here.
>  
> Dan S: class loading in the proposed JVMS: if you see $Value
>    1) first derive the VCC name and see if already resolved
>    2) if not - load the VCC, check properties and derive
>    (ed. note - if see VCC - lazily derive derived value class on touch)
>  
> ----
>  
> John sent out a proposed API for a secondary mirror (see email link above)
>    note: not for EA
>  
> Dan H: if ask for the same name for the secondary mirror what happens?
> John: only libraries can use the proposed API and library is responsible for interning the name - not the VM.
>  
> Remi: need “nest” automatically for secondary mirror
> John: yes eventually
> Karen: not EA - need to check if time during MVT
>  
> Remi: dynamic language implementor will want the same name - e.g. to get to shared static methods
>    today - because you can’t re-open a class folks generate ancillary classes to add static methods later
> note: for printing purposes it would be helpful to have a different way to represent the name
>  
> John: model on primitive type vs. wrapper type
>  
> VWithfield - propose for MVT - allow package private access - since there are no methods on the derived value class
>    and the value capable class can’t have any methods with vbytecodes since generated by javac
>    - plan to make private when we add factory methods to value classes with a compiler (and we have nest support)
>  
> Discussion of work needed to get to early access from various parties. See question above for early adopters
> on potential restrictions to get this to you sooner.
>  
> Teams need to re-assess timing assuming we want to make this available before we cross all the t’s and dot the i’s
> (you just have to recognize this goes against the grain for any virtual machine engineer), but we do appreciate
> that our first adopters would like to get this this summer while they have time to experiment and have shown
> lots of willingness to work with us)
>  
> Good news is: With the current JVMS (let’s get that reviewed and stamped), Remi is looking at modifying
> ASM so folks will find it easier to generate byte codes. Many thanks!
>  
> ASM needs:
> 1) new opcodes and overloaded opcodes
> 2) descriptor support
>  
> note: this is independent of condy
>  
> Maurizio - we would like to use that ASM internally whenever it is ready - that would make the MethodHandle API
> able to take advantage of existing optimizations for references that we haven’t done yet
>  
> So - goal is to have a binary snapshot available ASAP.
>  
> Maurizio suggested we look at the JVMLS workshop time separately - need to discuss that next meeting.
>  
> ——
>  
> Exposure of java/lang/__Value?
>  
> Hotspot uses this today internally for MethodHandle LambdaForms - generating e.g. vreturn for __Value
> (which is derived value class top type) . This is internal implementation magic - we pretend this is a marker class.
>  
> Note: instanceof and checkcast do NOT work with value types in MVT.
>  
> John: Longer-term: exploring QObject equivalent and a UObject which is at least a reference or value type
> When we support interfaces and generics for value types we will need a user story users can trust
>  
> Concern: ASM verification
> John proposed: use invokeBasic model - wormhole from untyped to typed which is ignored by the verifier
>  
> thanks,
> Karen
>  
>  
>  
>  
>  
>       
>       
>  
>  
> 