Valhalla EG minutes

[Karen Kinnear]

attendees: Tobi, Dan S, Simms, Frederic, Karen
corrections welcome.

1. JVMLS talks
LWorld - Tobi & Simms
Condy - Dan H & Paul Sandoz
Nestmates - Just a Small Change -> actual impact: Karen
LWorld discussion - multiple folks willing to participate if this is wanted

Abstracts (were) due May 25.

2. Nestmates
Reviewed and approved David Holmes’ update on java doc for java.lang.class::getNestHost()
http://mail.openjdk.java.net/pipermail/valhalla-spec-experts/2018-May/000694.html

key points:
1. clarified LinkageError vs. e.g. RuntimeError handling
2. clarified primitive and array class handling - member of nest consisting only of itself
3. all nestmates implicitly in same runtime package

Remi sent mail that 6.2 ASM is available supporting Nestmates, Condy and preview versioning - many thanks Remi!

3. Value Types
Karen described Towards Minimal LWorld discussion and additional thoughts:
http://mail.openjdk.java.net/pipermail/valhalla-spec-experts/2018-May/000674.html

Key messages:
1. We need to phase in the LWorld support 
    LW1: get minimal LWorld/LW1 out as Early Access binaries ASAP - goal pre-JVMLS
    LW10: initial preview version
   LW100: we got there
   and multiple stages in between

2. Scaled back LW1 requirements
   1. No support for erased generics: javac disallow
       value type may not be used for a type argument
   2. No requirement for for migration value-based-class to Value Type: nullability issues not yet resolved

3. LW10:
   1. support erased generics (but not specialized)
   2. preview quality
   3. may discuss other requirements, e.g. from feedback from EA users

4. Nullability discussion

1. Agreed on adding ValueTypes attribute

Decouple value type consistency checking from nullability discussion.
LW1 would disallow any classfiles to not buy in to the global consistency checking of being a value type.
Verifier can check value type/non-value type relative to valid bytecodes (defaultvalue/withfield vs. new/monitor*/putfield)

ed. note - see follow-on email: http://mail.openjdk.java.net/pipermail/valhalla-spec-experts/2018-June/000705.html

2. Nullability direction:

Longer-term goal: decouple non-nullability of a type, make this a property of a container
   could use this for atomicity and immutability

Dan H: long-long term: similar to Arrays 2.0, e.g. frozen arrays

3. Nullability handling for LW1 - very much still under discussion

Option 1:
LW1: all references to value types are non-nullable
  start with non-nullability as property of a container - specifically fields and arrays in the heap
  non-nullable fields are marked as ACC_FLATTENABLE 
      (LW1: all fields containing value types from ValueTypes attribute are marked ACC_FLATTENABLE, so remove source keyword)
  arrays of value types are by default non-nullable/flattenable
  
  
LW10: will need to evolve to handle nullable references to support erased generics
   will need to develop model for array handling that allows distinguishing arrays of value types that may contain null

Option 2:
   LW1: all value types are non-nullable - based on type
            verifier check to ensure static null not stored via putfield, putstatic, withfield, nor passed in invocation/areturn for value type signature
                 - to provide guarantee null is never seen in a value type signature
            use Object[] if you need an array that may contain null

4. verifier discussion
   Karen voiced concerns about guarantees that static null checking would ensure no dynamic nulls in value types in the longer term.
   Dan H: runtime checks would be prohibitive

AI: all see if there are holes here
ed. note:
    potential holes:  JNI: native method can return null
                              erased generics can return null for a value type, will need a way to support null
                              future: value-based-classes will be value types that allow null
   note: aastore does no verifier checks, the type-checks are dynamic, the null checks would also need to be dynamic

Dan H: worth exploring VT implement interfaces

5. ValueTypes attribute: 

  5.1 Value-type eager loading
     ed. note: see same follow-on email: http://mail.openjdk.java.net/pipermail/valhalla-spec-experts/2018-June/000705.html

    1. value type fields: pre-load (after pre-loading supertypes) only if flattenable (LW1: all in ValueTypes attribute flattenable)
    2. eager load for methods: at link time before preparation
    3. challenge: initialization of statics before loading type and getting a default value
      ed. note: see follow-on email on statics: http://mail.openjdk.java.net/pipermail/valhalla-spec-experts/2018-May/000699.html

 5.2 other uses of default value - must require class initialization
    e.g. arrays (anewarray, multianewarray)

6. JVMTI implications of ValueTypes attribute
   agreed: not remove entries, ok to add or reorder

7. Constructor - 
   LW1 will leave alone
   for LW10 - see email: http://mail.openjdk.java.net/pipermail/valhalla-spec-experts/2018-May/000680.html

Feedback on ideas above?
Dan H: like the idea of something smaller, early, need to study more

thanks,
Karen