RFR: 8200238: Reduce number of exceptions created when calling MemberName$Factory::resolveOrNull
claes.redestad at oracle.com
Mon Mar 26 15:51:29 UTC 2018
On 2018-03-26 17:15, Karen Kinnear wrote:
> 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?
Yes, we reach it, and by returning NULL there a null return is observed
on the java side,
regardless of whether or not I CLEAR_PENDING_EXCEPTION. I'd be happy to
> 2) with the change you just sent out - do you really get a performance improvement?
> I’m confused about where that comes from
By not throwing a new NSME from MHN_resolve_Mem, the effective number of
exceptions (shown by -Xlog:exceptions) is cut in half. On a startup
test that does 10
failed resolveOrNull calls, this equates to a reduction in retired
instructions by ~2M on my
machine, as measured by perf.
> 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.
More information about the core-libs-dev