> AI: What does reflection get_enclosing_class do if for example the enclosing > class has been deleted? NoClassDefFoundError
And if you do the same with an annotation, getAnnotations() skip the annotation. (Obviously isAnnotationPresent() and getAnnotation() does not work because they takes the class as argument) Rémi ----- Mail original ----- > De: "Karen Kinnear" <karen.kinn...@oracle.com> > À: "valhalla-spec-experts" <valhalla-spec-experts@openjdk.java.net> > Envoyé: Lundi 11 Septembre 2017 18:05:05 > Objet: Valhalla EG minutes Aug 30 > 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
