<html><head><meta http-equiv="Content-Type" content="text/html charset=utf-8"></head><body style="word-wrap: break-word; -webkit-nbsp-mode: space; -webkit-line-break: after-white-space;" class="">Bjorn,<div class=""><br class=""></div><div class="">Thank you for the corrections.<br class=""><div><blockquote type="cite" class=""><div class="">On Jul 5, 2017, at 5:10 AM, Bjorn B Vardal <<a href="mailto:bjornvar@ca.ibm.com" class="">bjornvar@ca.ibm.com</a>> wrote:</div><br class="Apple-interchange-newline"><div class=""><div class="socmaildefaultfont" dir="ltr" style="font-family:Arial, Helvetica, sans-serif;font-size:10.5pt"><div dir="ltr" class=""><div class="">> Bjorn: single representation for both value capable class and derived value class
<div class=""> </div>
<div 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.</div>
<div class=""><div class=""> </div>
<div class=""> </div>
<div 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)</div>
<div class=""> </div></div>
<div class="">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),</div>
<div class="">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.</div></div></div></div></div></blockquote>That makes more sense.<br class=""><blockquote type="cite" class=""><div class=""><div class="socmaildefaultfont" dir="ltr" style="font-family:Arial, Helvetica, sans-serif;font-size:10.5pt"><div dir="ltr" class="">
<div class=""> </div>
<div class=""> </div>
<div class="">> Bjorn: could hack using the different name as two views of the same thing</div>
<div class="">>    e.g. vbox/vunbox would need to swap names</div>
<div class="">>    (ed. note - please let us know if this is doable without heroic efforts)</div>
<div class=""> </div>
<div class="">I can make this work as long as there's a predictable prefix and suffix, so ";Q<name>$value" works.</div></div></div></div></blockquote>Thank you - very much appreciated.<br class=""><blockquote type="cite" class=""><div class=""><div class="socmaildefaultfont" dir="ltr" style="font-family:Arial, Helvetica, sans-serif;font-size:10.5pt"><div dir="ltr" class="">
<div class=""> </div>
<div class=""> </div>
<div class=""><div class="">> Dan S: class loading in the proposed JVMS: if you see $Value</div>
<div class="">>    1) first derive the VCC name and see if already resolved</div>
<div class="">>    2) if not - load the VCC, check properties and derive</div>
<div class="">>    (ed. note - if see VCC - lazily derive derived value class on touch)</div></div>
<div class=""> </div>
<div class="">It's not a requirement that the value class derivation is lazy, correct?</div></div></div></div></blockquote></div><div>Let’s double-check with Dan Smith at today’s meeting.</div><div><br class=""></div><div>The way I read 5.3 Creation and Loading in</div><div><a href="http://cr.openjdk.java.net/~dlsmith/values.html" class="">http://cr.openjdk.java.net/~dlsmith/values.html</a></div><div>it appears to allow lazy derivation as well as eager derivation, which I think is what we both want</div><div>since it allows implementations to optimize.</div><div>Our current derivation is also eager.</div><div><br class=""></div><div>thanks,</div><div>Karen</div><div><br class=""><blockquote type="cite" class=""><div class=""><div class="socmaildefaultfont" dir="ltr" style="font-family:Arial, Helvetica, sans-serif;font-size:10.5pt"><div dir="ltr" class="">
<div class=""> </div>
<div class=""> </div></div>
<div dir="ltr" class=""> </div>
<blockquote data-history-content-modified="1" dir="ltr" style="border-left:solid #aaaaaa 2px; margin-left:5px; padding-left:5px; direction:ltr; margin-right:0px" class="">----- Original message -----<br class="">From: Karen Kinnear <<a href="mailto:karen.kinnear@oracle.com" class="">karen.kinnear@oracle.com</a>><br class="">Sent by: "valhalla-spec-experts" <<a href="mailto:valhalla-spec-experts-bounces@openjdk.java.net" class="">valhalla-spec-experts-bounces@openjdk.java.net</a>><br class="">To: <a href="mailto:valhalla-spec-experts@openjdk.java.net" class="">valhalla-spec-experts@openjdk.java.net</a><br class="">Cc:<br class="">Subject: Valhalla EG minutes 6/21/17<br class="">Date: Fri, Jun 23, 2017 10:33 PM<br class=""> <br class=""><!--Notes ACF
<meta http-equiv="Content-Type" content="text/html charset=utf8" >-->attendees: Remi, Bjorn, Dan H, Dan S, John, Maurizio, Frederic, Lois, Karen
<div class=""> </div>
<div class="">AIs:</div>
<div class="">All: review Dan Smith’s proposals</div>
<div class="">   MVT JVMS: Specification for Value Classes: <a href="http://cr.openjdk.java.net/~dlsmith/values.html" target="_blank" class="">http://cr.openjdk.java.net/~dlsmith/values.html</a> - initial proposal</div>
<div class="">*** let’s pin this down ASAP so we - Remi for ASM, IBM and Oracle can deliver early binaries for early adopters to try</div>
<div class=""> </div>
<div class="">   incremental proposals for post early access (or maybe post - MVT TBD)</div>
<div class="">       Direct Value Class: Specification for Value Classes with Explicit Declarations: <a href="http://cr.openjdk.java.net/~dlsmith/values-declaration.html" target="_blank" class="">http://cr.openjdk.java.net/~dlsmith/values-declaration.html</a></div>
<div class="">       Specification for Value Classes with CONSTANT_ClassType: <a href="http://cr.openjdk.java.net/~dlsmith/values-classtype.html#values-classtype-4.1" target="_blank" class="">http://cr.openjdk.java.net/~dlsmith/values-classtype.html#values-classtype-4.1</a></div>
<div class="">All: review John Rose’s proposals:</div>
<div class="">      ConstantDynamic JVMS changes: <a href="http://cr.openjdk.java.net/~jrose/jvm/condy-jvms-2017-0620.html" target="_blank" class="">http://cr.openjdk.java.net/~jrose/jvm/condy-jvms-2017-0620.html</a></div>
<div class="">note: this is orthogonal to MVT</div>
<div class="">      java/lang/Class.java makeSecondaryClass: <a href="http://mail.openjdk.java.net/pipermail/valhalla-spec-experts/2017-June/000286.html" target="_blank" class="">http://mail.openjdk.java.net/pipermail/valhalla-spec-experts/2017-June/000286.html</a></div>
<div class="">                post EA</div>
<div class=""> </div>
<div class="">Hotspot and IBM:</div>
<div class="">  what could be available for early access  for early adopters to experiment with?</div>
<div class="">  revisit early access timing - if we were to set expectations that</div>
<div class="">     - model would be to deliver binaries and periodic binary updates to match the source builds. This is not a one shot delivery.</div>
<div class="">     - limit functionality (platforms, reflection behavior unspecified, no JVMTI, …)</div>
<div class="">     - performance improvements are not yet there, expect to come in incrementally</div>
<div class="">     - maybe verifier isn’t ready?</div>
<div class="">     - stability issues</div>
<div class=""> </div>
<div class=""><b class="">Potential early adopters: Ian Graves? Doug Lea? Others?</b></div>
<div class=""><b class="">    So - would you be willing to start experimenting with minimal value types even with the restrictions above?</b></div>
<div class=""> </div>
<div class=""><b class="">    We would find it helpful to get your feedback on</b></div>
<div class=""><b class="">       - the basic conceptual model</b></div>
<div class=""><b class="">       - usage model</b></div>
<div class=""><b class="">       - use cases - so we can optimize what you care about</b></div>
<div class=""><b class="">       - required features we missed </b></div>
<div class=""><b class="">    - so that when we ship this experimentally it is much closer to what you need</b></div>
<div class=""> </div>
<div class="">Model of usage:</div>
<div class="">1) Value-capable-class: created in java with annotation, javac generates a regular classfile with no new constant pool entries</div>
<div class="">or bytecodes</div>
<div class="">2) MethodHandles and ValueType APIs</div>
<div class="">     - this is the default model of usage</div>
<div class="">3) generated byte codes</div>
<div class="">    - you can generate your own byte codes to work on value types</div>
<div class="">    - at this point you can’t generate your own value type class this way (until we get to Direct Value Class support)</div>
<div class=""> </div>
<div class="">Constant Pool changes for Early Access:</div>
<div class="">1) proposal for a value class is:</div>
<div class="">      part I: CONSTANT_Class_info: UTF8: “;Q<name>;” // i.e. this would be a descriptor using a UTF8 string to speed up implementation</div>
<div class="">      part II: hotspot requests that we use a different name for the value type than for the value capable class</div>
<div class="">           implementation request - today we need unique strings to identify unique runtime types and this is baked in multiple places</div>
<div class=""> </div>
<div class="">     So propose: CONSTANT_Class_info: UTF8:”QFoo$</div>
<div class=""> </div>
<div class="">Where is the name exposed?</div>
<div class="">   in the constant pool when you generate your own bytecodes - in descriptors and class names</div>
<div class=""> </div>
<div class="">Dan S: Longer term: will declare a value class directly. The box first is a temporary approach in which we derive the value class.</div>
<div class="">Propose we not spend a lot of time here blurring the difference and needing to hide the derived value class.</div>
<div class=""> </div>
<div class="">Bjorn: single representation for both value capable class and derived value class</div>
<div 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)</div>
<div class="">   </div>
<div class="">Dan S. Longer term: we do want one declaration and two views based on the value class.</div>
<div class=""> </div>
<div class="">John: prefers Bjorn’s approach</div>
<div class=""> </div>
<div class="">Bjorn: could hack using the different name as two views of the same thing</div>
<div class="">   e.g. vbox/vunbox would need to swap names</div>
<div class="">   (ed. note - please let us know if this is doable without heroic efforts)</div>
<div class=""> </div>
<div class="">John: for hotspot - part of condy refactoring did part of the loaded class cache lookup changes that could be used here.</div>
<div class=""> </div>
<div class="">Dan S: class loading in the proposed JVMS: if you see $Value</div>
<div class="">   1) first derive the VCC name and see if already resolved</div>
<div class="">   2) if not - load the VCC, check properties and derive</div>
<div class="">   (ed. note - if see VCC - lazily derive derived value class on touch)</div>
<div class=""> </div>
<div class="">----</div>
<div class=""> </div>
<div class="">John sent out a proposed API for a secondary mirror (see email link above)</div>
<div class="">   note: not for EA</div>
<div class=""> </div>
<div class="">Dan H: if ask for the same name for the secondary mirror what happens?</div>
<div class="">John: only libraries can use the proposed API and library is responsible for interning the name - not the VM.</div>
<div class=""> </div>
<div class="">Remi: need “nest” automatically for secondary mirror</div>
<div class="">John: yes eventually</div>
<div class="">Karen: not EA - need to check if time during MVT</div>
<div class=""> </div>
<div class="">Remi: dynamic language implementor will want the same name - e.g. to get to shared static methods</div>
<div class="">   today - because you can’t re-open a class folks generate ancillary classes to add static methods later</div>
<div class="">note: for printing purposes it would be helpful to have a different way to represent the name</div>
<div class=""> </div>
<div class="">John: model on primitive type vs. wrapper type</div>
<div class=""> </div>
<div class="">VWithfield - propose for MVT - allow package private access - since there are no methods on the derived value class</div>
<div class="">   and the value capable class can’t have any methods with vbytecodes since generated by javac</div>
<div class="">   - plan to make private when we add factory methods to value classes with a compiler (and we have nest support)</div>
<div class=""> </div>
<div class="">Discussion of work needed to get to early access from various parties. See question above for early adopters</div>
<div class="">on potential restrictions to get this to you sooner.</div>
<div class=""> </div>
<div class="">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</div>
<div class="">(you just have to recognize this goes against the grain for any virtual machine engineer), but we do appreciate</div>
<div class="">that our first adopters would like to get this this summer while they have time to experiment and have shown</div>
<div class="">lots of willingness to work with us)</div>
<div class=""> </div>
<div class="">Good news is: With the current JVMS (let’s get that reviewed and stamped), Remi is looking at modifying</div>
<div class="">ASM so folks will find it easier to generate byte codes. Many thanks!</div>
<div class=""> </div>
<div class="">ASM needs:</div>
<div class="">1) new opcodes and overloaded opcodes</div>
<div class="">2) descriptor support</div>
<div class=""> </div>
<div class="">note: this is independent of condy</div>
<div class=""> </div>
<div class="">Maurizio - we would like to use that ASM internally whenever it is ready - that would make the MethodHandle API</div>
<div class="">able to take advantage of existing optimizations for references that we haven’t done yet</div>
<div class=""> </div>
<div class="">So - goal is to have a binary snapshot available ASAP.</div>
<div class=""> </div>
<div class="">Maurizio suggested we look at the JVMLS workshop time separately - need to discuss that next meeting.</div>
<div class=""> </div>
<div class="">——</div>
<div class=""> </div>
<div class="">Exposure of java/lang/__Value?</div>
<div class=""> </div>
<div class="">Hotspot uses this today internally for MethodHandle LambdaForms - generating e.g. vreturn for __Value</div>
<div class="">(which is derived value class top type) . This is internal implementation magic - we pretend this is a marker class.</div>
<div class=""> </div>
<div class="">Note: instanceof and checkcast do NOT work with value types in MVT.</div>
<div class=""> </div>
<div class="">John: Longer-term: exploring QObject equivalent and a UObject which is at least a reference or value type</div>
<div class="">When we support interfaces and generics for value types we will need a user story users can trust</div>
<div class=""> </div>
<div class="">Concern: ASM verification</div>
<div class="">John proposed: use invokeBasic model - wormhole from untyped to typed which is ignored by the verifier</div>
<div class=""> </div>
<div class="">thanks,</div>
<div class="">Karen</div>
<div class=""> </div>
<div class=""> </div>
<div class=""> </div>
<div class=""> </div>
<div class=""> </div>
<div class="">      </div>
<div class="">      </div>
<div class=""> </div></blockquote>
<div dir="ltr" class=""> </div></div><br class="">

</div></blockquote></div><br class=""></div></body></html>