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.go...@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 >> >> >> >> >> >> >> >
