-
Enhancement
-
Resolution: Fixed
-
P4
-
None
-
b10
MethodHandleNatives::resolve are used by both MemberName$Factory::resolveOrFail and ::resolveOrNull, the latter allowing speculative lookup of methods.
While the linkResolver code 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.
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).
This is related toJDK-8161588, which entertained the idea that we could make the expected cases of a speculative lookup not throw any exceptions at all.
While the linkResolver code 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.
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).
This is related to
- relates to
-
JDK-8200424 Windows build fails due to implicit jboolean to bool conversion
-
- Closed
-
-
JDK-8161588 MemberName::resolveOrNull cause and hide NoSuchMethodErrors
-
- Closed
-