RFR: 8161588: MemberName::resolveOrNull cause and hide NoSuchMethodErrors

Claes Redestad claes.redestad at oracle.com
Fri Aug 5 19:36:49 UTC 2016


Withdrawing this as clearing exceptions actually doesn't seem to get rid of
overhead(!), making this change moot. The overhead for my use case
is small but annoying.

Sorry for the noise.

/Claes

On 07/19/2016 12:17 PM, Claes Redestad wrote:
> Hi,
>
> please review this bug fix to ensure MemberName::resolveOrNull doesn't
> throw exceptions when speculatively looking up members that aren't
> there.
>
> HS: http://cr.openjdk.java.net/~redestad/8161588/hs.01
> JDK: http://cr.openjdk.java.net/~redestad/8161588/jdk.01
>
> This avoids throwing NoSuchMethodError etc just to be ignored, avoiding
> a performance penalty when looking things up speculatively (which is key
> to possible upcoming work to generate more JLI code with jlink).
>
> There's a pre-existing issue not dealt with by this fix in that the
> exceptions thrown in MHN_resolve_Mem are never observed, instead the
> exceptions thrown from various LinkResolver methods are observed. We
> could clear all pending exceptions in resolve_MemberName, but this
> breaks tests that are very particular about which exception is thrown
> when and where, thus I opted to add the clear_pending boolean to
> allow clearing the exception conditionally instead, keeping behavior
> identical for MemberName::resolveOrFail
>
> Thanks!
>
> /Claes



More information about the core-libs-dev mailing list