Valhalla EG notes April 10, 2019

[Karen Kinnear]

Attendees: Remi, Tobi, Dan H, John, Brian, Simms, Frederic, Karen

AIs:
1. Remi - list of P3 bugs for condy rfes
2. Remi - Amber combinator suggestion
3. Karen - forwarder example for which we will need a reverser
4. editor note - I asked Frederic to forward an example of random flattening/performance impact if
the vm chooses where to flatten for cycles

I. Condy - requests for java support for several smaller features
 - condy lambda
 - condy enum switch
 - condy constant arrays
 - future: lazy static final 

II. Lazy static final
  Remi exploring in lworld
     2 part init: getstatic, or if in same class - ldc locally
  experiments e.g. empty main - 100 static constants initialized in JDK and not yet read - will post (TIA!)

III. Valhalla offsite follow-up
Updated phasing email:
http://mail.openjdk.java.net/pipermail/valhalla-dev/2019-April/005555.html

1. moved null-default and value-based class migration L10 -> L20

2. circularity handling for value type fields - proposed experiment with vm detection
Remi: if VM determines where to “stop” flattening the results will be random locations - which will change performance
Karen: Frederic prototyping in progress - 
     - choice of field to flatten is random: based on dynamic loading order
John: give tools responsibility, so vm doesn’t make the decision, potential user model issue
(ed. note: more discussion to come - including options such as not flattening any field involved in circularity/performance cost, tool choice, user model choice)

3. Meaning of “L” descriptor
John: “L” descriptor is: “by pointer”, nullable, not flattenable, not pre-load
Karen: still under discussion how to indicate things like flattenable, null-free, …

4. Migration support: “forwarder”
http://mail.openjdk.java.net/pipermail/valhalla-spec-experts/2019-April/000912.html

Karen
  To enable value-based-class migration to null-default value types
     current proposal is to require source file changes with incremental benefits
     and to support migration via improvements in migration approaches
   - believe similar approach could be used to support allowing wildcards to work with species receivers
Brian: new word “forwarder” - not the same as existing bridges
   - classical bridges are not too horrible today (mostly shaken out)
   - new forwarder is actually bidirectional

Remi: Dynamically typed language call from java: must match signature
   - could use forwarder, does not work today with bridges

Brian: constraints on forwarders
1. same access controls
2. same name
3. local definition (vs. inherited)
will discuss explicit trade-offs
Remi: local definition not a big restriction - not too tight, not a big deal
Brian: could lose later, need for LW20

Karen: propose: all access flags and attributes for field and method forwarders match forwardee (except ACC_BRIDGE/ACC_SYNTHETIC or whatever)
Brian: must Abstract match? Will go through all bits and see which are important
Remi: today generate method with indy in it in dynamically typed languages
Brian: forwarding for client, may need to override forwarder
Remi: overriding - no way (ed. note - ??)
Brian: override original signatures - resolve to
Karen: 
  1. AI: email example where overriding (which is only relevant on selection) means reverser needed
  2. rather than forwarder refer to forwardeedescriptor - need to refer to either method_info or field_info
  (ed. note - this is NOT a methodref/fieldref - JVMS 4.6 method_info, JVMS 4.5 field_info, note that
   the forwardee has a code attribute as well as a descriptor_index)
  3. need a pair of adaptors - so we can generate the reverser
Brian: use asType in both directions
Karen: performance concern - the vm is not calling MH.asType
   I get that for LW20, L->Q: don’t need the full set, we are just performing checkcasts
   we will want vm internal subset identified
Remi: composition - may want several forwarders
Brian: all in the same class file?
  yes, in future e.g. Date -> LocalDateTime (LDT) - yes will need multiple forwarders
  initial milestone limited set
Karen: helpful to design with longer term goals
  concern user adaptors - tight restrictions
Brian: restrict tightly to start
Karen: could use a use case for multiple forwarders
Brian: e.g. A -> B -> C
   javac may be able to unroll to the real forwardee - so may be able to avoid
Remi: adapt different parameters
Brian: yes, potential cross-product
Remi: JIT - could inline adaptor
  Ok: with a 2 phase forwarder
   1. L/Q for L20
   2. for others :L100

5. Terminology bikeshed:

Brian: 
name for “value class”?
Consensus from email on “inline class”
Remi: ok with “inline” or “immediate”, “immediate” too long. Kotlin uses “inline” already
Dan H: concern: lose discussion history if rename value type to inline
Brian: treat as GC’s term value type
Dan H: must teach from scratch
Brian: those who know will get it, 99% need to be taught anyway
Karen: if we are revisiting terminology - can we have reference cover all classes (etc) and have a split?
John: e.g. JVMS uses reference generally - e.g. all a* bytecodes
  What about “indirect”?
Brian: carrier thing - indirect carrier for identity vs. inline class
  

6. RefObject vs. ValObject (new names coming)
Brian:
  coming around to interfaces
  then what is Object? if you say new Object - is it likely you want to be able to lock?
Dan H: any runtime benefit to making interfaces?
Brian: Not have to change superclass hierarchy
Dan H: verifier benefit if superclass rather than superinterface - verifier doesn’t do interface subtype checking - left until runtime
Brian: what if RefObject erases to Object?
  e.g. acmp issue
  - what if old code only wants classical Object
  - way to represent only RefObject without changing signature?
  - source RefObject -> binary Object ?
Dan H: future compatibility bigger concern
  - old code only want RefObject - could enforce in signatures
  - JDK needs bridges - perhaps rest could get away without bridges?
  - prefer class rather than interact : interface runtime check is a performance cost
John: even with erasure? vm has permission to perform strong speculation
Karen: concern 1: “magic” split with erasure proposal - same source generates two different binaries?
  - how do you know which the user meant? All Object or just RefObject?
  concern 2: if I understand the proposal - this would mean the authors of old code would be the ones that need to make a change
better if new code needs to make a change, 
John: better with World, shunt off newcomers, especially arrays
Karen: old code - work to ensure same performance
John: array loop performance challenges
Frederic: flattened arrays in the interpreter are worst case, need copies

7. MH combinators
Remi: AI: email another potential combinator for Amber
  indy with initial arg which is constant: can get 10-20x performance (e.g. formatter)
   - need GuardwithTest: if constant do this, else do that
John: asType - may not be quick correct - today it checks interfaces (does not honor the verifier convention)
    - also no null checks today
(ed. note - I’m confused - runtime has to make up for verifier lack today - isn’t asType - runtime?)
Karen: will forwarders include null checks?
John: yes: 
   primitive box/unbox
   maybe not checkcast if Interface<->Object // since verifier will let this through
(ed. note checkcast would be there for the runtime)
   may want asBridgeType with null checks


corrections welcome,
thanks,
Karen