Valhalla EG minutes 6/21/17
karen.kinnear at oracle.com
Wed Jul 5 14:12:30 UTC 2017
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
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.
> ----- 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
> 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
> 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
-------------- next part --------------
An HTML attachment was scrubbed...
More information about the valhalla-spec-experts