Attendees: Dan H, Tobi, Remi, Brian, Simms, Frederic, Karen corrections welcome (apologies for delay)
I. Value Types user model Brian: 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. Brian: 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). http://cr.openjdk.java.net/~jrose/values/template-classes.html Remi: concern: Templates are C++ like had issues with size of generated code like partial evaluation Brian: 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 thanks, Karen
