RFR: 8200238: Reduce number of exceptions created when calling MemberName$Factory::resolveOrNull

[David Holmes]

Hi Claes,

On 26/03/2018 10:08 PM, Claes Redestad wrote:
> Hi,
> 
> MethodHandleNatives::resolve are used by both 
> MemberName$Factory::resolveOrFail and ::resolveOrNull, the latter 
> allowing speculative lookup of methods.
> 
> While the linkResolver code this calls into in the VM will create and 
> throw exceptions for all cases where a method or field is missing, these 
> are caught by MethodHandles::resolve_MemberName and an empty handle is 
> returned instead. However, the outer method, MHN_resolve_Mem will always 
> create a new exception and throw it.

MethodHandles::resolve_MemberName doesn't "catch" exceptions from 
LinkResolver. They remain pending and will be thrown later unless 
replaced with a different exception - which sounds like what happens 
from your description. But both that and the unconditional clearing of 
the exception that you do now seem quite wrong! It may be okay to ignore 
a missing field/method but there can be various other exceptions thrown 
which should not simply be ignored/hidden. If an unexpected exception 
occurs then it should either become the cause of a higher-level 
exception, or allowed to propagate as itself (OOME, StackOverflow ...)

One of the changes that is coming as part of the JEP-181 (Nestmates) 
work is that LinkResolver access control will no longer convert 
OOME/StackOverflow etc into IllegalAccessError but let them propagate as 
is. There will also be the possibility of LinkageErrors being thrown due 
to nestmate checks.

It is not at all clear to me how the MH code is dealing with exceptions 
that come from this code.

David
-----

> 
> In case of resolveOrNull, we'll then ignore whatever exception is thrown 
> in the java code, so in effect we're creating and ignoring two 
> exceptions on a failed lookup.
> 
> We can cut this in half by passing a boolean to 
> MethodHandleNatives::resolve to indicate whether we're doing a 
> speculative lookup (resolveOrNull) or not (resolveOrFail):
> 
> Bug: https://bugs.openjdk.java.net/browse/JDK-8200238
> 
> Webrev: http://cr.openjdk.java.net/~redestad/8200238/open.00/

It doesn't look right to clear any pending exception rather than just 
the ones reporting a missing field or method.

> This is a small startup optimization for applications that have a high 
> miss rate (looks up a lot of methods that doesn't exist in the 
> pre-generated Holders).
> 
> Thanks!
> 
> /Claes
>