To add to the LW1 open issues: how we express constructors. The current
model (exposing a __WithField primitive) is adequate for early adopters
but will be a distraction (people are simply unable to understand the
notion that this is not the permanent model we're proposing.) I'd like
to scope out the costs of exposing a more traditional constructor idiom.
On 5/30/2018 1:41 PM, Karen Kinnear wrote:
Details for LW1:
Goals of LW1:
Support Early Access Binaries ASAP
Support immutable, identity-free value types that are subtypes of
java.lang.Object
Limitations:
No support for value classes as type parameters for generics (enforced by
javac)
No migration of value-based classes
In order to deliver this as quickly as possible, we want to decouple the
agreed-upon proposals from
the currently open issues.
Specifically, we are decoupling adding the ValueTypes attribute for
consistently identifying known value types from
the discussion of how we deal with nullability, which allows us to make
significant progress and narrows the open design issues.
This email details this initial step. We have done detailed exploration of
eager loading requirements.
=======
I. Support for ValueTypes attribute and value type consistency
Javac:
ValueTypes Attribute identifies value types known at compile time
Verifier:
Ensure specific bytecodes operate on match of value type vs. not:
(withfield, defaultvalue vs. new, monitor*)
Runtime:
Ensure consistency between assumptions of a type being a value type and
the actual type’s expectations when loaded.
Thanks to Frederic: improvement on consistency guarantees for being a Value
Type.
Checks for consistency will be performed and throw ICCE on mismatches between
ValueTypes attribute and actual loaded class is_value_type.
Clarification of terms:
“preloading” means loading before completion of loading for the declaring
class. This is only used for flattenable fields.
“link-time loading” means loading during the link phase for the declaring
class, which is used for all other uses of entries in the ValueTypes attribute.
1. *1 Flattenable fields:
preload value types used for local flattenable field descriptors listed in
the ValueTypes attribute
2. Local methods:
load value types in method descriptors (parameters/return) at link time,
prior to preparation
3. constant pool resolution:
all constant pool resolution will ensure value type consistency
4. References to constant pool descriptors: field and method descriptors
at resolution of target field and method descriptors, for all
parameters/return, ensure value type consistency
Interpreter:
specific bytecodes change behavior based on dynamic checks for is_value_type
JIT:
specific bytecodes change behavior based on dynamic checks for is_value_type
Open design issues for LW1
1. flattenable statics:
http://mail.openjdk.java.net/pipermail/valhalla-spec-experts/2018-May/000699.html
2. nullability handling for LW1.
I will send follow-up email exploring trade-offs.
thanks,
Karen
