Valhalla EG minutes March 13, 2019

Karen Kinnear karen.kinnear at
Tue Apr 9 16:51:05 UTC 2019

Attendees: Dan H, Tobi, Remi, Brian, Simms, Frederic, Karen
corrections welcome (apologies for delay)

I. Value Types user model
Value types user model: V, V? (V? value set including null) replace .val and .box
Don’t need all degrees of freedom.
This is a simpler story, will capture in a follow-on writeup.
Box model was tacky and the wrong mental model. Replace with a nullability modifier.

Remi: did not particularly like val/box model.

Feedback please:
  null-default (no zero in value set) vs. zero-default (no null in value set)
Reference, null-default value, zero-default value
nullability, zero ability, flattenability - get to pick 2: declaration and use site

Remi: Like concept - pick your zero
Brian: Class author does the bulk of the work: declaring null-default vs. zero-default
   no accidental zeros, not leak into APIs
Remi: if array: if zero, can call method, if null, can not

II. Substitutability
Dan H
  concern performance for existing applications with changes to acmp bytecode
  with naive acmp extra checks - regressions for native code 2.5-4% (DayTrader7 - java EE app)
  a few optimizations to skip additional checks
  a bit more regression on substitutability than on returning false
Brian: migration compatibility constraints: 
Karen: value types as subtypes of Object and Interfaces - have to handle those cases with acmp anyway
Dan: suggest API - explore identity, substitutability, equals - and then bind to operations
  biggest concern: can’t opt out
Brian: tension semantics vs. perf
  == was intended to be fasttrack for older hardware, pre-JIT - prior to calling .equals
Remi: concern security encapsulation
Dan: concern tree or graph: == could be slow based on complexity
  .equals implementations most start internally with == anyway
Brian: What if users were just to call .equals? 
Dan: concerned performance pothole when not expected - not want to migrate to value types and lost performance
 if erased generics: expect .equals - using LIFE model
Brian: == does not imply identity today, it works for primitives
  Kevin requested == be illegal and redirect to .equals
  maybe we picked the wrong default here
  can’t sell “false” as approach, == is important to users (not so much bytecode underneath)
  concern: performance characteristics
Dan: concernL how opt-in to substitutability
Karen: substitutability vs. equals? i.e. user overridable?
Dan: old code assumes LIFE
Karen: erased generics - old searches - I don’t remember precise numbers, but actually maybe 60% used LIFE
   other concern: non generics - use of Object and Interface - which don’t use LIFE model 
Brian: With LWorld, existing code will be exposed to value types
Dan: relying on == : primitives or identical - fast checks, old code not expecting substitutability checks
   performance concern
Brian: correctness concern as well as performance
Remi: 2 kinds of value types: e.g. Complex, Point - do not want a false return from ==
 e.g. Cursor, Optional - want encapsulation
Dan: Point, Complex - just want operating overloading?
Brian: don’t want to change semantics if you cast something to a super type
Dan: values performance depends on complexity of object graph
Remi if override equals and hashcode, want substitutability
Karen: propose LW2 EA binary - with a flag - and get feedback
Remi: already sent example: if lambda is a value type, == return false -> lose performance trick
Brian: Dan - is your concern performance of existing code or performance of new?
Perhaps explore API points?
Dan: looking for a way to opt-in to faster approach e.g. their .equals might be faster than substitutability
  costs for non-value types and existing code are biggest concern
Remi: what if change existing bytecodes from == to .equals?
Brian: difference between most code will work and all code will work
Remi: LWorld not a good idea?
Brian: migration was impossible before LWorld changed to moderately practical
Remi: concerns: so slow performance and encapsulation - defer to user?
Dan: operator overload -> defer to user?
Brian: biggest concern == not reflexive: x != x
Remi: Value Type NAN?
Brian: NAN - we hate with floating point, ok because infrequent
 All - thank about null-default/zero-default and stuff built on top
Dan: will go through this

III. Specialized Generics - translation strategy
Follow-on vm internal meeting to discuss class file format for prototyping for specialized generics,
including background reading of template class proposal (November 2017 - John Rose).

Remi: concern:
Templates are C++ like
   had issues with size of generated code
   like partial evaluation
  different from C++ templates
  lots of sharing, intelligent erasure, wildcards
Remi: challenge if represent a Tuple by a LinkedList - add a new Link and create a new Type
  - great if erase, if not, one type per link
Brian: migration path - erase reference types
Will have a longer discussion when we have a proposal


More information about the valhalla-spec-observers mailing list