RFR: 8200238: Reduce number of exceptions created when calling MemberName$Factory::resolveOrNull
karen.kinnear at oracle.com
Mon Mar 26 15:15:55 UTC 2018
Discussed with Lois. We think that it would make more sense to pass the new argument into MethodHandles::resolve_MemberName and at all three places that we currently CHECK_PENDING_EXCEPTION/return null there
- if speculative flag is set - CLEAR_PENDING_EXCEPTION before you return null
- and yes - do this for all three cases, not just the METHOD case
Couple of questions though:
1) do you actually reach the new code in MHN_resolve_Mem? Could you possibly add an assertion there that
there is no exception pending and/or print the exception if there is one pending?
With the CHECK_NULL in the call to resolve_MemberName I do not expect you to get here with a pending exception,
so the question arises as to when you would have a null resolved, but no pending exception?
2) with the change you just sent out - do you really get a performance improvement?
I’m confused about where that comes from
My apologies - I was incorrect - we are not converting Error -> Exception in MHN_resolve_Mem - so I
do not know why we are burying existing exceptions here - longer-term I think we need to clean this up
and as David points out - at least for the ResolveOrFail case - store the original exception as a cause.
> On Mar 26, 2018, at 8:08 AM, Claes Redestad <claes.redestad at oracle.com> 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.
> 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/
> 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 hotspot-runtime-dev