Bjorn, Thank you for the corrections. > On Jul 5, 2017, at 5:10 AM, Bjorn B Vardal <[email protected]> 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 <[email protected]> > Sent by: "valhalla-spec-experts" > <[email protected]> > To: [email protected] > 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 > > > > > > > > > >
