LW1 and ValueTypes consistency

[Brian Goetz]

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
>
>
>
>     
>     
>      
>
>
>
>