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