Notes from October 10 - corrections welcome - sorry for the delay Attendees: Tobi, Dan H, Remi, Brian, Simms, John, Frederic, Dan S, Karen
Background documents for next phase of Value Types: Entering the next phase of Project Valhalla - Brian - http://mail.openjdk.java.net/pipermail/valhalla-spec-experts/2018-October/000760.html <http://mail.openjdk.java.net/pipermail/valhalla-spec-experts/2018-October/000760.html> Values and erased generics - Brian - http://mail.openjdk.java.net/pipermail/valhalla-spec-experts/2018-October/000762.html <http://mail.openjdk.java.net/pipermail/valhalla-spec-experts/2018-October/000762.html> Q-Types in L-World 10 - John - http://cr.openjdk.java.net/~jrose/values/q-types.html <http://cr.openjdk.java.net/~jrose/values/q-types.html> John: described Q-Type as a restricted value set on an L-Type primary mirror is unconstrained and works for backward compatibility and is nullable advanced users can find special mirror with new API if they want to unbox, they can ask for the unboxed mirror Discussion of user model of boxing/unboxing vs. vm model which uses subtyping or possibly conversion Arrays: proposal is to NOT support array covariance for initial experiments [LPoint; <: [LObject; BUT [QPoint; is NOT a subtype of any other array (it is a subtype of LObject;) Note: explicit copying is required between flattened/non-flattened arrays Generics: Proposal is to support erased generics over L-Types and reserve reified generics for Q-Types, allowing phasing in of reified generics (LW100, i.e. a long to go still) after making value types available. Also - users opt-in to erased generics by boxing to e.g. Point.box. Goal is to not constrain LW100 specialized generics too much by erased generics plans. Longer-term vision is to have generic class - something like Arrayish<T>, which should work for value type or primitive or Object arrays. John: depends on how we handle array covariance as well as kind variants of array types Remi: goal of evolving [int as a [value type? Could we support primitives as value types before we support specialized generics? John: interesting suggestion Brian: we would need to be clear what int.Box would mean - currently proposing multiple “boxes” - current box: Integer, “lox” - lightweight box for a value type, - might need a new box for primitives to value type Remi: identity river: Karen: value types and their boxes have no identity, therefore there is no meaning to locking Brian: want a way to support user model of locking even without identity Karen: concern about granularity - false sharing on one side - false positives on the other Remi: j.l.Integer has no identity - but some are cached - can not lock reliably Brian: people do use it. Need to figure out more nuanced way to do this Nullable VT: Brian: challenge is many/most value types have no meaning for a default value of 0. concern: if a receiver is a default, uninitialized value - want NPE, we do not want the ability to invoke a method or access a field. We do not want to expose uninitialized default values to users option 1: javac handle this option 2: vm - add “nullable” value types, T.default treated as a null key question: when do we “normalize” T.default to be a null concern: “diversity of nulls” - if we have to check null and T.default at many bytecodes Also goal: user model of allowing a = null; and a==null; Exploring possible models Need to check possible role of verifier Dan H: concern - do we lose the benefits of guaranteeing Q-type is non-null? Brian: change Q-type to mean flattenable, rather than null-free believes we can still flatten and scalarize may need additional field since all bit patterns may already be used if we have a checkcast Q->L we can include a null check here to change T.default to a true null Karen: asked if we could explore a checkcast Q->L rather than a subtype check, provides a place for conversion John: not necessarily the place conversion happens, need to explore “normalization” points Karen: there are some value types for which all 0’s is valid so the default instance is valid, these are not “nullable”, you can’t normalize to null “nullable” value types - willing to pay for an additional field Brian: ensure no invalid receiver for invocation/getfield keep same bytecodes for generic code Dan H: concern - potential source of java puzzlers Brian: concern about vulnerabilities - if V.default is not valid - if you skip a constructor like serialization does … Dan H: if need null - maybe use L-Type? Or not a candidate for VT? Brian: We want flattening optimizations Remi: Do we still need L-Type? Brian: nullable Q-types are more expensive than null-free values get benefits of flattening/density Dan H: C# model? Brian: Not exactly - VT in C# are mutable - initialization races Remi: C# calls default constructor Dan H: with [VT in C# if you load an element, do you get something constructed? Remi: yes - call constructor for each cell Brian: timing holes can be observed Dan: need null checks on scalarized nulls Karen: concern about additional costs for checking new “null-marker” field Brian: worth the costs for those who want the flattenability for arrays Frederic: outside JIT - rest of vm will pay huge cost if there is a specific check for each type - lose cache efficiency benefits faster if vm tag or all “null-marker” fields at the same place rather than having a user-specified field Brian: users may be able to re-use an existing field in some cases Karen: can we explore not observing non-constructed value type? That solves the uninitialized leak issue. Explore default constructor model? Frederic: if value class implements nullable, could provide default factory Remi: could have two kinds of value types, those with a user-defined default and those without Karen: maybe no-arg factory good enough - on need for interface or flag Remi: do we always load the class of a value type before creating a default? Frederic: yes - we always load and init before creating an instance or array thanks, Karen
