Valhalla EG notes Mar 27 * clock change *

[Karen Kinnear]

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