AI: David Holmes - Proposal for reflection APIs for nestmates ( thanks David for volunteering) AI: Dan Smith - updated Condy JVMS AI: Karen Kinnear - for nestmates - transitive overriding example email
Attendees: Bjorn, David Simms, Dan H, Frederic, Lois, John, Karen I. Nestmates JVMS comments: (Thanks to David Holmes) 1. IAE due to issues with nestmates such as - NCDFE or not listed in nest host member list or other resolution error We all agreed we want to report more information than just an IAE possible approaches: - add a cause - additional information in the message - possibly subclass of IAE for nestmates? (ed. note - while access checking is likely to be the place where lazy nest host resolution occurs, it might also happen due to a reflection request) Responses welcome. 2. InvokeInterface change to support local private method invocation - proposal is to make that independent of class file version. Change in behavior: old ICCE will now succeed. No issues with mix-n-match class file versions. All will support local and old versions won’t have nestmates. Dan H pointed out that we have reserved the right to go from an error to a success case. Summary: EG was good with change. This will be a strict subset of the new behavior for old classifies. 3. Reflection Need a specific API proposal for when we get nest host resolution errors or there is a mismatch in nest membership. For each API - do we return e.g. null or a failure or a subset of members? If I ask for all my nest mates - do we need to eagerly resolve them? No to returning string names of nest mates John Rose: what if we were able to return the upcoming ClassRef, i.e. an unresolved reference which could then later be resolved which could get an appropriate resolution error at that time? — if this is going to ship in the same timeframe as support for Constable - maybe this is a better approach going forward. 4. Preparation vs. Selection Dan H said that Karen’s proposal made sense to him (yay! and many thanks) and clarified some of the intended loader constraint handling. So we are ok with the preparation changes to the JVMS if Dan S agrees with Karen’s description as well - i.e. we think they match :-) Karen owes brief summary of transitive overriding including some examples - to double-check the overriding modifications. No other nest mate JVMS issues were raised. === II. Release timing: Intention is that 18.3 contain ConstantDynamic with class file version update. No other class file changes are anticipated. Nestmates are targeted for early in the 18.9 cycle so it gets bake time. Other language changes in 18.3 - LVTI other? === III. Condy JVMS Dan Smith is working through some improvements - in internal review. Should be available soon. 1. 5.4.3 Clarification of pre-condy expected behavior: Indy - if resolution fails with a LinkageException for s given BCI, we need to record the exception and rethrow. Successes for a given BCI also need to be cached and return the same result. (Oracle is currently fixing a bug with that). If a VM error pass through unchanged, else wrap in BSME. 2. InvokeWithArguments Handling for megaarguments - e.g. removing the limits and turning the tail into varargs. This matches what we do i source code. goal: scale BSM (8 bit limitation today) treat BSM as if method descriptor from constant pool - all Object except for boxing note: no method descriptor in constant pool call matches > 256 args on stack - and we do not want to change the JVMS for that. So - looking to find a short simple way to allow this in the specification without having to precisely restrict implementation. In future we plan to clean this up with the BsCI mechanism. 3. Renaming Constant_Dynamic Constant_DynamicCallSite (yes - renaming indy as well) 4. Implementation clarification For non-ConstantCallSite - if setTarget is called - what is the expected behavior? If SetTarget is called - the JVM MUST notice this and - replace any caching, deopt/recompile etc. - it is not valid to setTarget to null - it must be a non-null MethodHandle and the proper type The Callsite returned must be the same for the same BCI for indy, but the target itself is changeable. 5. ldc_w Just ensuring we all are expecting that ldc_w condy works for double and wide 6. Consider using a MethdHandle for ldc rather than a field descriptor? John: intention condy is to indy as get static is to invoke static indy uses a name&type for a method type and condy uses a name&type for a field type building on the existing JVM language split between methods and fields in future - may use MethodTypeRef and ClassRef goal is to benefits from combinators, and languages that want very untyped BSM args. Concern is a bootstrap attribute index which is shared between indy and condy. It has to be an indy BSM - super type of both is java.lang.Object today. thanks, Karen
