Reminder, next meeting Wednesday Sept 13, 9am PT/noon ET/ new dial-in: https://oracle.zoom.us/j/5249803466
AI: All - review feedback on JVMS for nestmates for meeting on September 13th AI: Dan/Bjorn - do some experimentation with condy and give feedback on condy JVMS AI: All - nestmates attribute name proposals for Dan Smith AI: Dan Smith - invoke interface allowing private method invocation - is it ok to allow for older class file versions? AI: All - for nestmates - send to Dan Smith (and copy us all) implementation paths that would need to check for nest mate membership - so we can ensure the JVMS reflects potential LinkageErrors etc. AI: Maurizio - send example to Bjorn of code that works today, but would not work with eager nest top loading AI: What does reflection get_enclosing_class do if for example the enclosing class has been deleted? AI: Spec leads: discuss with Groovy & Scala folks any issues with removing ACC_SUPER support. Also whether this change needs to be class file version specific. Attendees: Remi, Bjorn, Dan Smith, John, Frederic, Lois, Maurizio, Karen MVT JVMS 1. getfield Remi: getfield bytecode for reading of field in Derived Value Class needs similar special handling as vwithfield in allowing the Value Capable Class read access to a private field in the DVC. Dan ok with proposed change Question: timing of nestmates relative to MVT so we could propose VCC and DVC as nestmates in MVT? Answer: Expect MVT to be available as early access, so before nestmates Q: Remi: How do you add to a nest if you can’t add to the nest members attribute? A: John: You can add dynamic nest members Editor’s note: I think we need to clarify what reflection shows Implementation note: Remi: vwithfield currently has a bug - VCC can not change the field in DVC - throws IAE ==== Condy JVMS: Remi: Request for a true constant pool constant - today restricted to LDC or indy in BSM Want to use for constant pool patching like unsafe.defineAnonymousClass Bjorn: can we dynamically load the BSM name? John: Larger changes could lead to security issues. We are expecting MethodHandle Combinators. Want constant pool template abilities, prefer to use MethodHandles as template carrier. Goal is to quantify over types not over names Bjorn: BSM args can be condy? A: Yes Discussion of implementation optimizations for condy. Note it uses a BootstrapMethod. Remi: bootstrap issue - can’t use lambdas - just like today you can’t use BSM until e.g. java.lang.invoke is loaded John: think about constant lambdas during bootstrap. Longer term AOT and jlink should help with condy Karen: concern about JVMTI spec and redefineclasses ability to change attributes, so BSM attribute could change. John: sent an email reply John: Condy phasing: 1) basic condy 2) jumbo arty with args for BSM in general 3) BootStrapCallInfo - API point - later 4) Constant_Group - even later - not yet spec’d Lazy resolution may be delayed, initially all resolution will be eager Remi: Constant_Group in constant pool or as an attribute? John: due to size - potentially 1000’s, maybe attribute Bjorn: what is a “kiddie pool”? What about constant pool holes? John: specialization - plugs small number of constant pool holes [editor’s note: John - what was a kiddie pool referring to?] Dan Smith: Why 2 arguments? What a Lookup and a separate BSCI? John: Put Lookup separately - it is uniquely security sensitive Remi: Lookup isn’t constant John: can LDC a Lookup ==== Nest mates Remi: Good with not changing invokespecial Naming bikeshed: What about changing “MemberofNest” to “Nest” - similar to superclass John: original challenge was the direction - was this the declarer/owner of nest or a member? See AIs for attribute name proposals. Q: Are the invoke interface changes classfile version specific? Note: Can still do invoke special of a local private interface method since it falls under the superclass method invocation If Invokeinterface throws an exception today for invocation of a private method, is it ok to eliminate this error in future with existing class file version? AI: Dan to investigate Note: check current TCK tests John: LONGER TERM: goal to deprecate invoke interface and just have a single virtual invocation with either a MethodReference or an Interface MethodReference. Editor’s note: internally sounds like both IBM and Hotspot would continue to use an internal byte code - at least for now - the MethodReference and InterfaceMethodReference rules are different, and for hotspot the caching of resolved method is different - for classes we need a virtual method table index, for interfaces we need an interface method table index relative to the super interface, i.e. two pieces of information Karen: Future: would like to evolve away from ACC_SUPER allowing invoke special to refer to an indirect super class which requires re-resolution relative to the direct super class. John: File a specification RFE and get started. Karen: Need javac to stop using invoke special on java.lang.Object references that have not been overridden at compile time. John: longer term goal: stricter vm - AI: discuss with Groovy & Scala folks any issues with this change. Also whether this change needs to be class file version specific. Dan: Bigger discussion - can we remove support for older class file versions? Remi: Sees 1% still running 1.0, 1.1. Tools like ASM can choose not to support John: defacto policy - continue to run older version Maurizio: Need to clarify in specification the timing of checking nest membership. We do not want this in the verifier since it can cause errors in code that works today. If you take an existing example of code in which javac generates a trampoline to access for example an outer class member, if you then delete the outer class, or if the inner class can not see the outer class due to it being loaded by a different class loader - today if you run code that does not use the trampoline it will succeed. With nestmates, if the outer class is the nest holder, if you delete that class, then you can not run the inner class since the verifier will fail trying to check nest membership. Bjorn: propose load supers and nest top at the same time - issue if a subclass is the nest owner, you can run into circularity issues, so proposed delay until after loading the class but before verifying the class to avoid circularity. Maurizio: propose changing the specification to first touch i.e. first access check of a private member trying to touch a nest mate Dan: note: if the member is actually private, should not need to perform the nest mate check, so no need to touch the nest — method handle, access checks which need to know membership would trigger the check and potentially throw an exception. i.e. any path that would check nest membership. Bjorn: agreed with proposal Karen: Dynamically adding a class into a nest should throw an exception for an invalid nest mate. Remi: A dynamic check would throw a more meaningful error at a time that would be expected - e.g. an IllegalAccessError with a meaningful message (or cause) AI: send to Dan Smith - implementation paths that run into checking nest membership Bjorn: Issues with checking nest membership - not find a nest top, not claim me in the nest [Bjorn - my notes were not clear on what you were asking] John: For example, an IAE may wrap a LinkageException Karen: Reflection - what should reflection return when it runs into errors finding nest members e.g. if you ask for all Possible approach? What does get_enclosing_class do today? T Remi: for dynamic languages - use reflection to check if you can do something so need behavior to be the same as byte code behavior
