Corrections welcome - I confess I had a fever while taking notes - so particularly at the end, my notes are less coherent.
For the meeting Wednesday June 7, we need to discuss short-term MVT constant pool representation for value types - CONSTANT_Class_info with “;QFoo;” vs. CONSTANT_Q/CONSTANT_Value . So please bring raw data on conceptual and implementation trade-offs between the two proposals. Valhalla EG 5/24/17 Attendees: Bjorn, Dan H, John, Dan Smith ,Frederic, Harold, Maurizio, Brian, Vlad, Lois, Karen Proposed presentations on MVT: J1: Bjorn and David Simms JVMLS: Bjorn and Karen: overview, Bjorn and Frederic: Implementation Deep Dive Schedules: JDK9 - EG working out open issues expect to delay a small amounbt, new schedule not final until updated vote future release cadence - goal ~ 6 months between releases Early Access: approval to make EA binaries available on java.net using common EA license, working out details MVT Early Access: need to work out implementation schedule with IBM and Oracle teams - in part dependent on JVMS draft of changes Condy (ConstantDynamic) update: John & Brian goal 1. raising BootstrapMethod static argument limit to s to the 64-1 (from 251) variable arity - package as an array which is unlimited if short arg list: invoke, if long, invoke with args both behaviors aligned, so specification doesn't have to specify line between short and long javadoc almost ready Dan H: note: java language today limits to 251 goal 2. support lazy resolution - resolve in BSM new BSM mode: allows catching exceptions from subsidiary constant resolution today we push arguments, proposing pushing the number of arguments, so the BSM can pull the arguments lazily Expose a way for the BSM to get the arguments Dan H: is this a BSM attribute index or a CP index? Karen: we hope this is a BSM attribute index - to reduce constraints on the runtime implementation Dan H: Need to work out requirements across redefinitions John: not specify if return old or new values Dan H: useful for expression trees in constant pool - mostly constant except for 1 or 2 parameters goal 3. Allow writing BSM more like writing ordinary methods John: Also want groups of constants to not consume CP indices ==== Constant Pool handling for Minimal Value Types (John) short-term goals: 1. value type opcodes must be able to disambiguate value type operands for verifier 2. no vm implicit conversion between Lmode and Qmode (or IJFD modes) editor's note: we need to revisit constant pool handling for MVT at our next meeting - and and focus on the short-term requirements. Need to discuss in the context of a JVMS draft with Dan Smith. This decision is the long pole on being able to deliver an early access binary. note: short-term we have 2 separate classfiles: with a primary and secondary mirrors long-term goals: 1. "Modes" - single class with two "modes"- Lmode and Qmode, so implied relationship 7 total modes: ILFDLQU, explicit at bytecode level verifier tracks modes 2. Descriptor: specify Q vs. L mode 3. There is also a union type U mode Dan H: This implies that a QType must have a header so that we can dynamically determine if we have a QType or an LType John: The header can be virtualized - e.g. in an array header or container or stored elsewhere in compiled code key point we agree on: we must always have a typed value 4. UObject would be a top type of "any", QObject would be a top type for any QType (ed. note: is this accurate? Or is UObject top type for any type that has both Lmode and Qmode?) Bjorn: ok with "any" on stack, but not ok in heap 5. Still no implicit conversions between LFoo and QFoo. Could be an implicit conversion from QFoo to UFoo, but not between any of the other types and not UFoo to QFoo 6. Belief that on the stack QFoo has the same representation as UFoo so only 1 carrier type (ed. note: need to understand more here) implementation note: The Qmode and Lmode must both use a single stack slot to allow a union type. You can ask a Qmode for size and layout (ed. note: need to make a chart of LFoo, QFoo, UFoo behaviors) Maurizio: Can UFoo do things LFoo can not? (ed. note: sorry didn't track the answer here) UFoo is a tagged union of QFoo and LFoo Brian: Still exploring: QInterface (ed. note - I thought it was UInterface so implementable by LFoo or QFoo. Does that mean implementable by any LBar even if it is not a boxed value type? I assumed yes?) also: QObject, QComparable John: need for UTypes: 1. interfaces: need to handle receiver of value or non-value 2. type variables - vs. bytecode splitting - goal of sharing bytecodes with a type parameter that is sometimes L and sometimes Q 3. top type for UObject 4. LambdaForm - need for value type top object like QObject today, with type variables will need UObject longer term Maurizio: how far should JVMS go for MVT? MVT issue 1: hide QObject? Internally today we are using java/lang/___Value - we don't need a common parent - we could use a wild card marker - current uses are for vreturn in LambdaForms so we don't need to specialize for each value type, and for method signature parameters note: if verify LambdaForm - we need to be able to do special handling for this limited top type for value types Dan H: note IBM not using the top type in implementation - not yet needed - different approach to LambdaForm implementation - not yet 292 templates for MethodHJandles - so need to find out implementation options before we decide here John: with Valhalla Value Types - top types will exist (although they may be interfaces not classes) Frederic: today - top type needs restrictions - not used as a field or array element, more like a wildcard MVT issue 2: CONSTANT_Value vs. CONSTANT_Type vs. CONSTANT_Class extensions? John: bytecode must know modes requirements: - verifier must be able to determine value type vs. reference without additional eager class loading (ed. note: this won't be true in future for embedded fields) Bjorn: always resolve to LType today and if QType, go to the secondary mirror trade-offs: option 1: different bytecodes - e.g. vgetfield vs. getfield, multivnewarray vs. overload anewarray/multianewarray Dan H: note that get and set resolution storage is short on bits so overloading would be cleaner if we had two different constant pool slots, with no risk of trying to share (ed. note: this implies to me that for a given BCI, in MVT at least, we want different constant pool slots, not a model in which we have for instance a mode indirection to a shared constant pool slot) Today: using naming convention ($Q) hotspot proposed: CONSTANT_Value_info J9 proposed: CONSTANT_Q - I think the name is different, but the concept is the same John: longer term: UTypes will have class Foo, mode U, with a single classfile deriving 2 types Dan Smith: constant pool entry sharing? Maurizio: long-term goal: if in future a class changes declaration to be a value class, want this to still work. Easier if bytecodes are common and constant pool reflects type Karen: longer term typed bytecodes note: instanceof, checkcast - for L only for MVT: LDC is only LTypes also