LW1 and ValueTypes consistency

Karen Kinnear karen.kinnear at oracle.com
Tue Jun 5 16:49:37 UTC 2018


John also brought up a question about ensuring consistency of the ValueTypes attribute with actual value types for descriptors
which refer to an array of value types.

For ensuring global consistency, I’d like to propose that we do check ValueTypes consistency for descriptors containing arrays with base elements
in the ValueTypes attribute. If at some point we find that there is a reason not to, then we could reconsider.

thanks,
Karen

> On Jun 1, 2018, at 4:14 PM, Brian Goetz <brian.goetz at oracle.com> wrote:
> 
> 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
>> 
>> 
>> 
>>             
>> 
>> 
>> 
> 



More information about the valhalla-spec-experts mailing list