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

[Claes Redestad]

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...).

/Claes

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.
>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
>>

-- 
Sent from my Android device with K-9 Mail. Please excuse my brevity.