Reminder - the US changed clocks last weekend, Europe did not. Also there will be no EG meeting March 27th.
Attendees: Brian, John, Remi, Frederic, Tobi, Karen I. BSM CallInfo and symbolic use of constraints - upcoming doc from John 2. Generic Specialization Requirements - upcoming doc from Karen http://cr.openjdk.java.net/~acorn/Generics%20in%20LWorld%20Requirements.pdf 3. Template Proposal expansion - upcoming doc from John Link to Template Classes: http://cr.openjdk.java.net/~jrose/values/template-classes.html Link to Model 3: http://cr.openjdk.java.net/~briangoetz/valhalla/eg-attachments/model3-01.html I. Generic Specialization and class file: Brian: approach from two perspectives - language model -> class file to enable sharing and runtime What is a class, species, mirror? Migration and backward compatibility John: Template proposal allows single source to define both template and the class at the same time Brian: “puns” with the meaning of class today - java class, class file, live type, … John: working on JVMS draft for templates e.g. how are names used, what constant pool entries need to change chapter 4 is fairly straightforward, get in trouble in chapter 5 with resolution with mix of class name and template parameters each of which might have a separate defining loader Brian: In Model 3 we just kept strings and gave up the loader issues Remi: can solve this at runtime, like a MethodType Remi: need to ensure look at requirements relative to other languages, not just java John: let us know what degrees of freedom are missing Brian: e.g. languages with covariant generics will be disappointed Note that all languages that want to interoperate with java need to understand java’s generic type system so we don’t force all to use raw types Remi: Need to know up front how holes are filled John: All constant pool references in a class can be templated, including superclass and superinterface - allows other languages to give other supers to each species names in bytecodes are used in two ways: 1. resolved: e.g. constant_class : “active” , “live” 2. quoted, not resolved: “passive” or “flat” would like: if quote a name, don’t make me put live values in it, want flat UTF8s Karen: client that defines the species resolves the live types for the type parameters, they may not be visible to the template class. So we need a way to store both the UTF8 and the already-resolved live type. John: Might fall back on Object if not denotable by template class Karen: we need to retain loader constraints John: maybe extend loader constraints e.g. List<List<… - there may be a point at which we need a fallback API points need passive names, not live types other than the receiver Karen: overriders need to distinguish List<Foo, class loader 1> from List<Foo, class loader 2> Also - redefineclasses needs a way to mark the live types type parameters which were resolved in another context, since we can not re-resolve them John: can re-execute condos and indys with redefineclasses … (zoom crashed) Brian: Type inference truncates e.g. ListMT extends Comparable<T extends …> today cuts off at 2 levels, to truncate to a finite type John: could use Object here Brian: added link (above) to Model3 for concepts from the language perspective - mostly still holds together Karen: does not include the sharing requirements John: goal for methods: unshare smallest possible piece of CP, if hot, unshare more goal for classes: subset of species metadata Remi: Do we need sharing? Is a prototype possible Brian: Model 1 prototype was a separate class file with on sharing, no wildcards Karen: My interest is the semantic sharing requirements the internal metadata sharing is an implementation choice Brian: Species all share the same class share wildcard at language level share a subset of statics - which needs to be clear in class file [editor’s note - see Generic Specialization Requirements for Karen’s understanding of the sharing requirements] John: goal - share bytecodes generic method: caller may create a generic method and put in his own constant pool, so reusable by him open issue - does it need to be reusable ty other callers Remi: Not want to discuss a class specialization mechanism that does not work for method specialization John: Want MethodHandle as specialization handle in addition to types Brian: Might need a double dispatch for generic methods Challenge: generic methods are generally nested in generic classes Old: treated inherited dynamically, but actually static Johnn: implies - in class file format - perhaps support for multiple classes Brian: today: outer/inner - 2 class files, could benefit if entire nest in one class file with shared type variables challenge: backward compatibility with existing class file names John explore 1 class file with multiple templates Brian: e.g. generic method with a lambda initializer - desugar to a method - which class file? Nice if same segment II. Acmp John: Are we willing to accept substitutability as a not too terrible approach since the alternatives are worse? Brian: yes Remi: No Tobi: Understand where Brian is coming from return false =- is hard for the user biggest concern: performance impact & cost of substitutability John: Do you need to prototype and measure cost on IBM JIT? Or ok with hotspot numbers? Karen: Hotspot prototype has measured performance on existing code, i.e. cost to non-value type users and it was not significant. YMMV, point is that is possible. We have not optimized substitutability, so no numbers on cost for value types Note: code cache size varies by implementation, and will vary for other value type uses, so not clear the meaning of measuring for hotspot. John: could take existing wrappers, e.g. j.l.Integer, call them value types and measure performance Remi: Not like returning false either Understand Brian’s concerns with reflective issues 2 other options: substitutability test vs. call equals challenge: == changes the encapsulation model, equals is provided by the author JohnL how handle backward compatibility? Remi: Call equals only for value types Brian: Kevin B and Remi uncomfortable want: in generic code: == or .equals paradigm -> .equals only in an ideal world all would use .equals Can we give useful semantics and demote == at the same time? javac could encourage .equals == we have a constraint that we don’t want to break existing code Remi: System.fastEquals - only for Object John: could invent new names for semantics or performance Brian: Need to invent anyway, then decide what to make to == Remi: If provide a subsitutitability test mechanism there is no author control, want opt-in Brian: like all-zero value John: Need to think about the balance for the junior java programmer Remi: === on value type should map to ,equals Brian LWorld: Users will not have to decide, just the author Remi: Not compile == on VT, require .equals Karen: Interface/Object - you do not know statically Remi: acmp doesn’t work today for String or j.l.Integer (ed. note - notes might be inaccurate) Brian: yes it does Brian: Goal is no existing code breaks, some performance, could guide away from == Karen: folks opt-in to value type encapsulation Remi: concern substitutability test Brian: each issue will create some legacy constraints locking, array covariance, equality John recommend call .equals Remi implies value type should call .equals if substitutability is not the right answer. Only works inside the class Brian: Most value types will be happy with substitutability, some may want to opt-out Remi want opt-in John: think about int Brian: let’s figure out an alternate mechanism then figure out the default Remi: value record - all fields visible, no encapsulation issue Brian Complex, Point, numerics, tuples, - no encapsulation cursors, native pointers - may want encapsulation AI: let’s figure out mechanisms then map APIs John: need a translation strategy Remi: if both same value class, then check John: one approach is methods: e.g. in chat ValObject::isSame(x){ return System.substEquals(this, x);} Brian: e.g. “NAV” - not a value, or a bit, perhaps not an upscale to java code to determine corrections welcome, thanks, Karen