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
