RFR: 8161588: MemberName::resolveOrNull cause and hide NoSuchMethodErrors
claes.redestad at oracle.com
Fri Aug 5 21:54:09 UTC 2016
Right there are some oddities in this code which I haven't fully grasped, such as throwing new errors when there's already some pending...
Still, having a way to speculatively resolve members without the exception overhead is on my wish list, I misread the current macros and mechanics thinking clearing the pending exception would avoid the upcalls (intuitively/naively in my mind the exception creation was deferred to the java/native boundary...).
Coleen Phillimore <coleen.phillimore at oracle.com> skrev: (5 augusti 2016 13:47:53 GMT-07:00)
>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
>>> 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,
>>> a performance penalty when looking things up speculatively (which is
>>> 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
>>> 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
Sent from my Android device with K-9 Mail. Please excuse my brevity.
More information about the hotspot-runtime-dev