Valhalla EG reminder for November 21, 2018

[Karen Kinnear]

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