Valhalla EG notes Feb 13, 2019

[Karen Kinnear]

Attendees: John, Remi, Dan H, Tobi, Simms, Karen

AI: Karen: resend John’s Template Class proposal: http://cr.openjdk.java.net/~jrose/values/template-classes.html
AI: Remi: write up proposal on specializing parameters to defineClass

I. DH: Locking options: put stake in the ground:
Throw exception - consensus

II. JR: Generic Specialization: Template class refinement

Propose we do at least one prototype for specialization mechanisms this year.

1. Class file is still chief entity
constant pool: more articulated, as are class, field and method

goal: share constants and bytecodes as much as possible
LWorld helps here

Constants: change signatures to add reified type parameters in descriptors
   - model 3 generated new classfiles, lost all sharing
Therefore: constant pool needs to be partially shared and partially specialized

Proposal: constant pool segments
Holes: fill with parameterized types
Requirement: No holes in the concrete by the time you get to a reference.
  Actually no holes by the time you get to verifying the species

RF: Concern about resolving too early if specialize CP
JR: Risk - we need an experiment
RF: wants greater dynamicity, possibly fully dynamic
JR: In the VM: we can’t always do late binding - e.g. heap layout - need full information early
RF: agree layout needs early info
      generate specialized class by filling hole when defining the class

JR: Entity model:
  segmented constant pool
  1 global segment
  local segments depending on 1 or more holes, tree structured to at least depth 2

Hole kinds: field type, dynamic constant, method type, MethodHandle
structural inheritance of constraints
Fill hole when we specialize a CP segment

DH: global segment seen by others?
JR: yes - resolved at most once
DH: condy and MH: lookup dependent on instantiation

JR:
  fill class holes when load/define a class/species, before referencing - i.e. field or method reference
  class_info, method_info, field_info refer to segment
  class template, method template ,field template - must specialize constant pool and then instantiate

Load class for specialization by providing hole values
(ed. note: provide live types)

Open question: how to represent generic method more generic than enclosing class

DH: CP indicies globally numbered?
JR: yes. segments are not overlays
DH: named segments?
JR: based on 1st constant in the segment
  rules for referential integrity and placement of constants in segment

DH: each specialization CFLH/redefinition or 1 per template?
JR: open - default yes
(ed. note - need to revisit this one - earlier assumption was redefinition of template class, not each species)
JR: also nested generics with a shared constant pool, e.g. in future an inner class could share the same class file

RF: What should be shared/not shared?
Would like to see done dynamically, specialize parameters to defineClass
- JR had to leave

DH: JVMTI and general tooling issues
KK: working on sharing requirements
  class
  species
  specialized
  conditional
note: sharing requirements are: class-wide and per-species, there is nothing shared across a subset of species.
Conditional (possibly “where” syntax) determines if a method for example will be part of any given species

KK: other open issue: raw vs. erased - and best way to deal with backward compatibility
During the meeting asked if virtual methods/virtual fields are only needed to deal with raw/wild types - answer was yes.
(ed. note: after meeting - found another case - which I can’t recall at the moment)

RF: client level proposal: old generics vs. new generics
   option 1: client with old generics not reference code with new generics
   option 2: not have to recompile client code to use it, need virtual dispatch
Proposal: embrace reuse as central design.
   Constant pool specialization - want to be careful about adopting java generics semantics.
   Other languages, e.g. Scala can’t use this - slightly different generics semantics

KK: Is there anything we could add to the class file that would make it easier to support generics in other languages?
RF: wants to do a prototype at runtime, with no java semantics in the design
KK: would it be useful to have information in the class file and language-specific specializers?

RF: future: use Lookup.defineClass with 1 dynamic parameter
  at runtime the dynamic object is like a static of the species
  no representation of species at compile time
  no reified type in constant pool
KK: Does this imply no sharing at all?
RF: Yes
RF: Derive species when needed - ask for specialization, create new if none exists, and intern
  Mark if a field or method is specialized
DH: Can a descriptor refer to specific specialization?
RF: No: dynamic check at runtime
DH: JIT engineers: if this model depends on JIT magic to work, concerns about startup especially in constrained environments
RF: specializing a class vs. method are different, maybe JR’s model for classes
  tradeoffs:
      not want java generic semantics in vm
      if full template specialization, can’t have sharing
  Swift: template: either generic code or compile time inline and specialize - based on caller/callee
KK: concerns about performance cost of virtual field/virtual method additional indirections
   What are the sharing requirements?

RF:      generic methods - just want to share resolution, not share data
   segment for each combination of type parameters too much
DH: only specialize for value types, reduces the problem

RF: Haskell eg. Linked list which encodes the type of the next link or tuple as linked list
  if CP specialization - never call with exactly the same type
DH: If it hurts …
RF: currently works with erasure. Concern slow if new specialization for each link

III. RF DynamicValue attribute
Another project Remi will lead and create JEP
  language level: static lazy final
  improve startup by allowing init with Condy at first access of individual static

Drawbacks: opt-in at source
  change in semantics
  in static block - there is a lock
  condy BSM can execute multiple times

corrections welcome,
thanks,
Karen