attendees: Remi, Dan H, John, Frederic, Lois, Mr Simms, Karen AI: Dan H/Karen - meet offline to discuss expected behavior today due to JVMS overriding rules AI: all - feedback on Nestmate Reflection API email thread I. Nestmates specifications
1. JVMS overriding rule checking: - Dan H reported that IBM has different results from the tests Oracle provided. Will follow up to understand differences 2. Reflection proposed APIs: http://cr.openjdk.java.net/~dholmes/8188075/webrev/raw_files/new/java/lang/Class.html#getNestHost() Summary: isNestMateOf: returns true if succeeds (even for self), false if any error getNestHost: returns Host if succeeds, otherwise returns “this” if none or resolution error getNestMembers: gets statically defied members, including host first, will throw LinkageError if any fail to resolve Works for Remi. Others - feedback on email thread please 3. JVMTI for Nestmates Karen proposed concern that today’s JVMTI specification which allows changing attributes could cause problems if we were to decrease access. Remi pointed out that it could also cause problems if we were to increase access. Propose: modify JVMTI rdedefineclasses restrictions to not allow changing NestHost or NestMembers attributes. Editor’s note: Dan S is working on a minor update to the NestMates JVMS II. Constant Dynamic 1. valid REF_kind for BootstrapMethod specification change in 4.7.23: JDK 9 JVMS: Accordingly, the reference_kind item of the CONSTANT_MethodHandle_info structure should have the value 6 or 8 (§5.4.3.5 <https://docs.oracle.com/javase/specs/jvms/se9/html/jvms-5.html#jvms-5.4.3.5>) Condy JVMS: The method handle typically has reference_kind REF_invokeStatic, pointing to a static method designed specifically to act as a bootstrap method. Offline Paul Sandoz pointed out that this is non-normative text so not validated. The question was what values are valid: answer: REF_invokeStatic, REF_NewInvokeSpecial and Remi came up with a REF_InvokeVirtual if you had a method in the Lookup class that took a String and MethodType, i.e. the first static argument would therefore be a Lookup. Thanks! Testing otherwise throws Summary - ok to leave the specification as is, we just wanted to make sure we covered all bases in our understanding and therefore testing. 2. circularity handling: JVMS for Condy: 4.4.13 The referenced entry in the bootstrap_methods table must not refer, directly or indirectly, to this CONSTANT_Dynamic_info structure. JVMS for Condy: 5.4.3.6 As a special condition, if resolution is attempted of a dynamically-computed constant which is already in this process of resolution in the same thread, the attempted re-resolution may terminate immediately with a BootstrapMethodError, and it must eventually throw an exception instead of looping infinitely. Syntactic - within the same class file circular references e.g. ConDy -> BSM with a static arg of the same ConDy Semantic - this includes both circularity due to BSM code or due to cross class file link Agreed semantic circularity could only be detected at runtime. John proposed alternatives for syntactic checking: 0. do nothing - no checks at load/verify time 1. check loops at class load/verify time 2. precedence order on BSM records - BSM can not have reference to static argument which is a constantDynamic which refers to an earlier BSM Discussion: Remi prefers option 0. ASM builds constants based on order of instructions. If you add instructions it changes ordering. Dan H: make sure we support use cases in which we add changes to code and constant pool. John: make sure this works with Pack200 [ed note: make sure this will work in future with specialization and potential sharing of partial class files] Dan H: we have to detect the dynamic case anyway, and that is a superset check for the static case Karen: Agreed - from a runtime perspective there is no benefit in an additional check. Question is - is this easier on tools? John: Is there a concern that tools which process a class file with a recursive syntax and re-write could run into recursion doing the rewrite? Remi: ok if you read garbage and get a StackOverFlow when rewriting consensus of the meeting - option 0. Wording of 5.4.3.6: John - worded to allow StackOverFlow today. Future explicit check could throw BootStrapMethodError Dan H - SOE is natural - what is the benefit of the explicit overhead to generate BSME? Is there a risk of forbidding cases people want to use? John: in far future - may want to remove cycle constraint and have tools allow it. Note that BsCI with lazy resolution is tolerant of cycles that are not executed Summarize: - leave 5.4.3.6 which describes throwing exception on cycle. VM throw SOE - no significant value in early detection - tool vendors can refuse cycles as they see fit [ed. note - would this remove the line from 4.4.13? Or is that non-normative text so we are disallowing without static enforcement?] 3. Renaming of CONSTANT_InvokeDynamic to CONSTANT_DynamicCallSite John personally recants this proposal. Special reason - in future may want ldc of CONSTANT_InvokeDynamic and want the BSM return to convert a CallSite to a MethodHandle for ldc, or a MethodHandle to a ConstantCallSite for an indy One use case would be for static types in the constant pool, i.e. lazily initialized ConstantValue static finals Note ldc of CONSTANT_InvokeDynamic would SHARE the result III. Class File Versions for experimentation John reminded us of the model he has proposed of exploring a private use area for major versions for experimentation. Proposed 0XE000 and above. Folks were ok with the proposed range. Remi pointed out the need for minor versions - so for instance you could test with MVT and Condy by setting a single major version and multiple minor versions. JVMS will add a paragraph that allows this - such that standard versions will not accept these classifies. In practice a flag could be added to enable an experimental version. No registration planned, squatters rights. thanks, Karen
