RFR: 8200238: Reduce number of exceptions created when calling MemberName$Factory::resolveOrNull
david.holmes at oracle.com
Mon Mar 26 13:16:41 UTC 2018
On 26/03/2018 10:08 PM, Claes Redestad wrote:
> 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.
> 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).
More information about the core-libs-dev