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
