RFR: 8161588: MemberName::resolveOrNull cause and hide NoSuchMethodErrors
coleen.phillimore at oracle.com
Fri Aug 5 20:47:53 UTC 2016
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.
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.
> On 07/19/2016 12:17 PM, Claes Redestad wrote:
>> please review this bug fix to ensure MemberName::resolveOrNull doesn't
>> throw exceptions when speculatively looking up members that aren't
>> 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
More information about the hotspot-runtime-dev