notes from Valhalla meeting 5/24/17

[Karen Kinnear]

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