RFR: 8200238: Reduce number of exceptions created when calling MemberName$Factory::resolveOrNull

[Claes Redestad]

Karen,

On 2018-03-26 17:15, Karen Kinnear wrote:
> Claes,
>
> 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

ok.

>
> 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 
add more
assertions.

>
> 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 
created
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.

Right.

/Claes