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
