Valhalla EG reminder for November 21, 2018
karen.kinnear at oracle.com
Mon Nov 19 17:19:49 UTC 2018
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
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
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
-------------- next part --------------
An HTML attachment was scrubbed...
More information about the valhalla-spec-experts