The need for a UFoo; is not clear to me. So correct me if i'm wrong, u-bytecodes are bytecodes for representing something similar to T and Foo<T> in Java but for the VM with the supplementary constraint that T can be either a primitive, a value type or class.
I do not see how does UFoo; fit in this scheme ? Is it to represent Foo<?> ?, i do not think so, Foo<?> can still be represented by it's erasure, Foo, we just need a way to represent '?', which is any (java.lang.Any ?). Is it to represent Foo<? extends Bar>, i do not think so, again, it can be represented by it's raw type with an explicit cast from any to Bar when we need the value represented by '? extends Bar'. so why do we need UFoo; ?? Rémi > De: "Karen Kinnear" <karen.kinn...@oracle.com> > À: valhalla-spec-experts@openjdk.java.net > Envoyé: Mardi 6 Juin 2017 01:21:59 > Objet: notes from Valhalla meeting 5/24/17 > 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
