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
