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
