Valhalla EG minutes June 6, 2018

[Karen Kinnear]

Attendees: Remi, Tobi, Dan H, Dan S, Frederic, Karen
Corrections welcome.

AIs:
1. Karen: proposal for value types consistency checking
2. Karen: updated proposal for handling statics

No nestmate or condy topics.

Value types:

1. ValueTypes attribute
Remi: need to ensure that constant pool Constant_Class and Descriptors for fields and arrays all know about value type-ness
Checkcast also needs to know

Karen: described evolving proposal: 

There are two kinds of Value Types Consistency checks: 
checks vs. real loaded value type and caller-callee consistency checks. All mismatches throw ICCE.

 - instance value fields that are flattenable require pre-loading, i.e. load the value type if it is in the Value Types attribute prior to completion
of loading the declaring class, to allow field flattening. Check vs. real.
- local methods: any parameter/return in the ValueTypes attribute eagerly loaded during linking, prior to preparation. Check vs. real.
- constant pool resolution for CONSTANT_Class always checks consistency vs. real. This covers anewarray, multianewarray, checkcast, new, defaultvalue, …
- resolution of a field or method in another class, caller-callee consistency checks.

Dan S asked if a descriptor has a type which is not in the ValueTypes attribute, do we perform consistency checking?
For the constant pool resolution, we always check, whether the value type is in the ValueTypes attribute or not.

Dan S: If ClassA and ClassB both believe that Point is not a Value Type (not in their ValueTypes attribute) but it actually is,
we need to allow the null case. 

Dan S: expect this to be analogous with class loader constraints
Frederic: Agree with class loader constraint checking locations as the places to perform the checks. Storing ALL the expected value types
and expected non-value types has too high a cost.

Dan H: class loader constraint analogy makes sense

AIs: Karen - email proposal for value types consistency checking

2. Flattenable static fields
Challenge is allowing a flattenable static field to contain an instance of the declaring class

Karen: note: for handling statics, due to class initialization requirements, we need to ensure that any mechanism (bytecodes and
otherwise) that expose default value instances trigger class initialization - e.g. need to add anewarray and multianewarray to the specification
along with defaultvalue

LW1: Plan is to ban flattened fields from statics so we don’t need to deal yet with either circularity issues or fully working out class initialization issues.

Current statics proposal exploring:
  - VM can initialize a default value at preparation time, without executing java code, based on the size and layout information of the type, without requiring that the type yet be initialized
  - concern about potential leakage of an instance of the value type, i.e the default value prior to the value type class initialization
  - bytecodes are fine, but we are investigating the alternate accessors: reflection, methodHandles, JNI, JVMTI, …

Remi: Goal in future  remove <clinit> and initialize statics per field
   - allowing both eager and lazy field initialization
   - perhaps use indy
   - Spring problem with startup (also depends on external environment)
   - let’s not wait very long for this

ed. note - bytecode examples are cleaner than the alternate accessors here - which assume a fully initialized class before exposing
handles, jmethodID/jfieldID etc.

AI: Karen - updated proposal for flattenable static fields for POST-LW1

3. Constructor idiom:
Dan S: Problem is a language problem
   - do we expose withfield?
   - do we expose something like a constructor
   - this is not a vm issue
   - needs further exploration

Remi: Need to ensure this handles migration from class to value type
Dan S: value-based-classes today which are eligible for migration all require private constructors
   if other classes migrate - there is a risk of not ensuring binary compatibility if they do not have private constructors
   VBC assumptions: no identity assumptions, private constructors

Javac exploring a lint mode to check identity assumptions of value-based-classes - not for LW1

4. LW10 goals:
  Support value types as type parameters for erased generics
  Definition of “working”
      - not throwing NPE when e.g. store null when you pass in an array of value types

Remi: if erasure is to Object, must accept writing null
Karen: agree: must find a way to accept null

Remi: If the Type Parameter bound is a Value Type - can we avoid having to accept null?
   note: you can not extend a Value Type

Remi: Also make sure this works for the case in which 
    ClassA type parameter is bound by Object
    ClassB extends ClassA, bound by Value Type

Karen: LW10 supports value types as type parameter for erased generics - goal is working,
optimization not required
Later LW>10 support for specialized generics - if you have a non-nullable array of ValueTypes, will allow specialization
which will provide performance optimization

Remi: If you forget the bound (i.e. do not allow a bound to be a VT) and forget specialization for now
   For erased generics, need to be able to store null
   At read time, need to cast
   note: non generics have similar issues with Object/Interface, [Object/[Interface

Karen: exploring three possible directions:

PlanA: handle nullability at the language level and erase to nonnullable value types or nullable objects at the vm level
PlanB: container model, opt-in to nonnullability for heap containers, leave carrier types: local/operand stack/method args null agnostic
PlanC: need two different actual types - needing to also change descriptors and carrier types

Remi: What if we were able to transform null to a default value?
Karen: first challenge is - if you were to write null, record default value and read it back - you don’t get the same answer - this is a source code surprise
  Second challenge - we don’t have space for a nullability bit to distinguish a null as unset vs. a valid 0 in locals, registers, etc.
  If you can figure out a way to do this - it would make life much easier

Challenges:
1. ensure we have no user visible semantic changes migrating from erased generics to specialized generics
  - ok if performance improves

2. Arrays - a big challenge
   - how do we create arrays, how specify if nullable or not?
   - copying - definitely start with explicit conversions
   - array covariance - we need to be extremely clear here on what we require and what we can provide

Remi: Today when arrays break the type system, we throw ASE

Dan S: could build on ASE - e.g. frozen arrays, nullability - may be some leeway here
   e.g. sam array with different runtime configuration?

Frederic: Brian would like javac to warn if you expect a runtime exception

Remi: Maybe erase at the vm level to the same array?

thanks,
Karen