Reminder - we will have our usual meeting Wednesday Dec 20.
attendees: Remi, Tobi, Dan H, Mr Simms, Lois, Frederic, Dan S, John, Karen
Corrections/clarification welcome
I. Condy - targeted for JDK 18.9/jdk 11 for current JVMS version
- note: next phase of Condy - with lazy resolution for BootstrapMethod
static arguments - will be LATER than jdk11
II. Nestmates - futures
phase 2: proposal for sealed classes
- Class or Interface - can only be extended by nest members
- JDK 11 also looking to add Lookup.defineClass with private mode that
allows dynamically extending the nest - based on
having been given a Lookup.
III. Nestmates JVMS review:
1. selection and overriding rule changes - are they class file version
dependent?
Dan S: NO - the changes are universal
editor’s note - let’s discuss again - just to clarify - when the JVMS added
support for transitive overriding - that was based on
the class file version of the class containing the overriding method
2. selection changes
- Dan H and Karen believe this is correct as written, covers the issue
well and thank you for the examples
3. Dan H: access control error handling clarification - if access control
check causes e.g. resolution which can throw NCDFE, then we throw
that error, we do not wrap in an IAE with cause, right?
Dan S: correct
John - no subtype of Error covered all
4. Nestmates JVMTI spec update
Believe we need a change here regarding the new nest mate attributes
Karen: propose we do not allow NestHost or NestMembers to change
choice: 1. disallow change
2. allow adding to NestMembers
AI: Hotspot & J9 - double-check how complex this would be to implement,
note requirement that re-resolution needs to return
the same result, so if we allowed adding to NestMembers, attempts to access
a private member of a non-nestmember should
fail resolution with an IAE - and needs to continue to fail even if we
change it to become a nest member
5. Nestmate reflection requirements
Remi: does reflection reflect the static or dynamic nestmates? If not the
dynamic ones - how else could you discover them?
IV. Class Specialization - Template proposal
Remi: propose that rather than early template copying and optimization per
specialization, move the
specialization to the JIT
- do not specify Q-Types lots of places
- try to have the same byte code, so do not specialize byte codes or
constant pool
- let JIT optimize
John: agree with not specializing byte code (model 1 & 2 explorations)
- template class reduces the number of classes loaded
- depends on riddled constant pool segment
- any method only depends on root constant pool segment, does not need
specialization
Remi: why holes in the constant pool?
John: how else do you express the variants?
Remi: too powerful?
John: want to do other things. Goal: formalism to allow expressing what C++
templates can do with more runtime safety
Let the JIT optimize specialization - including methodHandles
Remi: stage 1 of generics - only need Q-Type information is for layout
stage 2 generics: template class
Karen: If in future primitives can be represented as value types (hard to
do/get performance) - with L-World - there will be
a reduced need for generics
John: still need wildcard support, e.g. need holes in the constant pool to
inject field descriptor
Remi: How do you inject a type argument?
choices: 1) inject type argument - push type vs. 2) BootstrapMethod -
pull type
John: document allows condy and indy with holes
for each specialization, condy or indy would need separate resolution
Remi: could we get stage 1 specialization in Valhalla VT?
John: cruel to do specialization without language support
Remi: With Value Types - see a path for class species - method species - not
so clear
John: calculus of template classes can solve reified generics on methods
- need a method specializer -> gives you a MethodHandle
- named linkage - to match against a species
(editor’s note: I didn’t follow how you pick a species to then search for
the method?)
- issue: expand vtable slots - not want infinite - e.g. vtable slot for
each set of type variables on generic method
- we need a translation strategy not vm magic
Remi: concern about memory for infrequently used
John: holey constant pool - only use where it adds value
- strategy includes lots of erasure, inlining, loop optimization,
coroutines
- note profiling fails with generics
- hole based templates give us some expressiveness
- goal: flattened data structures, hints to JIT for profiling
Remi: drawback - size of metadata
- would like generic methods approach without hole based templates
John: like Haskell Type Classes?
- like Brian’s shadow instances? can often statically link at a given
use point
- holey template
- new hooks to express variants/invariants, at execution becomes
invariant
- generic methods - confine variance e.g. to private inner
helper class - which author could do explicitly
Remi: what about based on type argument on stack?
John: concern performance cost of non-generic code - which needs to do the
checking - we started with extra args on stack model, bound to constants -> led
to constant pool
- if you do the same specialization twice - reuse - do not need to
make a new one
- channel info mostly through constant resolution
Remi: what if you had a type arg or species that then was treated specially
John: e.g. 2 entry points - 1) general 2) need specialization
- want only 1 method, with multiple “displays” of bound constants
- this gives you a single pointer (e.g. register ) for piece of
constant pool, rather than one per variable
Remi: what if instead of segment of constant pool - varied type argument -
since lifetime is stack based
Karen: if this is a field descriptor - lifetime is not stack based
Remi: what if introduce a T-type in descriptor?
Karen: we need to explore where we need type descriptors - e.g. Q-Type or
possibly T-Type
thanks,
Karen
