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
