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

[Coleen Phillimore]

Claes,  I did look at this code and it looked a bit strange, but the 
existing code looks strange too.  I'm not sure why it breaks the normal 
rules of TRAPS/CHECKS.
Coleen


On 8/5/16 3:36 PM, Claes Redestad wrote:
> 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
>