Minutes Valhalla EG Oct 11 2017

[David Holmes]

On 13/10/2017 8:26 PM, Karen Kinnear wrote:
> 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.

This is tracked as:

https://bugs.openjdk.java.net/browse/JDK-8187768

I propose to set any exception that occurs when trying to perform the 
access check, and the access checks fails, as the cause of the IAE that 
is thrown. It is worth noting that pending exceptions are not checked in 
this code at present so it is possible to proceed through different 
access checks and eventually determine access is permissible, even if 
one or more checks triggered an exception.

> 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.

Tracked as:

https://bugs.openjdk.java.net/browse/JDK-8189163

> 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.

This is tracked as:

https://bugs.openjdk.java.net/browse/JDK-8188075

The ClassRef idea is intriguing - but it would need to be ready to ship 
before mid-December if the nestmates work is to be pushed on schedule. I 
find it hard to see how to define a Class based API now that would be 
able to evolve to a ClassRef based API in the future.

> 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.

I propose this is also tracked by:

https://bugs.openjdk.java.net/browse/JDK-8189163

We may need additional tests here.

Thanks,
David
-----

> 
> 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
> 
> 
> 
> 
>