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
