Valhalla EG minutes Dec 6 2017

[Karen Kinnear]

Reminder - we will have our usual meeting Wednesday Dec 20.

attendees: Remi, Tobi, Dan H, Mr Simms, Lois, Frederic, Dan S, John, Karen
Corrections/clarification welcome

I. Condy - targeted for JDK 18.9/jdk 11 for current JVMS version
    - note: next phase of Condy - with lazy resolution for BootstrapMethod static arguments - will be LATER than jdk11

II. Nestmates - futures
  phase 2: proposal for sealed classes
     - Class or Interface - can only be extended by nest members
     - JDK 11 also looking to add Lookup.defineClass with private mode that allows dynamically extending the nest - based on
       having been given a Lookup.

III. Nestmates JVMS review:
    1. selection and overriding rule changes - are they class file version dependent?
    Dan S: NO - the changes are universal

editor’s note - let’s discuss again - just to clarify - when the JVMS added support for transitive overriding - that was based on
the class file version of the class containing the overriding method

   2. selection changes
      - Dan H and Karen believe this is correct as written, covers the issue well and thank you for the examples
   3. Dan H: access control error handling clarification - if access control check causes e.g. resolution which can throw NCDFE, then we throw
       that error, we do not wrap in an IAE with cause, right?
      Dan S: correct
       John - no subtype of Error covered all 

4. Nestmates JVMTI spec update
    Believe we need a change here regarding the new nest mate attributes
    Karen: propose we do not allow NestHost or NestMembers to change
     choice: 1. disallow change
                  2. allow adding to NestMembers
    AI: Hotspot & J9 - double-check how complex this would be to implement, note requirement that re-resolution needs to return
    the same result, so if we allowed adding to NestMembers, attempts to access a private member of a non-nestmember should
    fail resolution with an IAE - and needs to continue to fail even if we change it to become a nest member

5. Nestmate reflection requirements
    Remi: does reflection reflect the static or dynamic nestmates? If not the dynamic ones - how else could you discover them?

IV. Class Specialization - Template proposal
    Remi: propose that rather than early template copying and optimization per specialization, move the
    specialization to the JIT
       - do not specify Q-Types lots of places
       - try to have the same byte code, so do not specialize byte codes or constant pool
       - let JIT optimize
   John: agree with not specializing byte code (model 1 & 2 explorations)
       - template class reduces the number of classes loaded
       - depends on riddled constant pool segment
       - any method only depends on root constant pool segment, does not need specialization
    Remi: why holes in the constant pool?
    John: how else do you express the variants?
    Remi: too powerful?
    John: want to do other things. Goal: formalism to allow expressing what C++ templates can do with more runtime safety
              Let the JIT optimize specialization - including methodHandles
    Remi: stage 1 of generics - only need Q-Type information is for layout
              stage 2 generics: template class
    Karen: If in future primitives can be represented as value types (hard to do/get performance) - with L-World - there will be
              a reduced need for generics
   John: still need wildcard support, e.g. need holes in the constant pool to inject field descriptor
   Remi: How do you inject a type argument?
      choices: 1) inject type argument - push type vs. 2) BootstrapMethod - pull type
   John: document allows condy and indy with holes
      for each specialization, condy or indy would need separate resolution
   Remi: could we get stage 1 specialization in Valhalla VT?
   John: cruel to do specialization without language support
   Remi: With Value Types - see a path for class species - method species - not so clear
   John: calculus of template classes can solve reified generics on methods
        - need a method specializer -> gives you a MethodHandle
        - named linkage - to match against a species 
      (editor’s note: I didn’t follow how you pick a species to then search for the method?)
        - issue: expand vtable slots - not want infinite - e.g. vtable slot for each set of type variables on generic method
        - we need a translation strategy not vm magic
    Remi: concern about memory for infrequently used 
    John: holey constant pool - only use where it adds value
        - strategy includes lots of erasure, inlining, loop optimization, coroutines
        - note profiling fails with generics
        - hole based templates give us some expressiveness
        - goal: flattened data structures, hints to JIT for profiling
     Remi: drawback - size of metadata
         - would like generic methods approach without hole based templates
    John: like Haskell Type Classes?
          - like Brian’s shadow instances? can often statically link at a given use point
          - holey template
               - new hooks to express variants/invariants, at execution becomes invariant
               - generic methods - confine variance e.g. to private inner helper class - which author could do explicitly
    Remi: what about based on type argument on stack?
    John: concern performance cost of non-generic code - which needs to do the checking - we started with extra args on stack model, bound to constants -> led to constant pool
          - if you do the same specialization twice - reuse - do not need to make a new one
          - channel info mostly through constant resolution
    Remi: what if you had a type arg or species that then was treated specially
    John: e.g. 2 entry points - 1) general 2) need specialization
          - want only 1 method, with multiple “displays” of bound constants
          - this gives you a single pointer (e.g. register ) for piece of constant pool, rather than one per variable
    Remi: what if instead of segment of constant pool - varied type argument - since lifetime is stack based
    Karen: if this is a field descriptor - lifetime is not stack based
    Remi: what if introduce a T-type in descriptor?
    Karen: we need to explore where we need type descriptors - e.g. Q-Type or possibly T-Type

thanks,
Karen