Valhalla EG minutes 6/21/17

Fri Jun 23 20:33:05 UTC 2017

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

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.openjdk.java.net/pipermail/valhalla-spec-experts/attachments/20170623/1b2289ed/attachment.html>