Re: Valhalla EG minutes 6/21/17

[Bjorn B Vardal]

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

 

 

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

 

 

> 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?

 

 

 

----- 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: 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 - 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

       Specification for Value Classes with CONSTANT_ClassType: 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

note: this is orthogonal to MVT

      java/lang/Class.java makeSecondaryClass: 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