RFR(XS): 8143897 :Weblogic12medrec assert(handler_address == SharedRuntime::compute_compiled_exc_handler(nm, pc, exception, force_unwind, true)) failed: Must be the same

[Jamsheed C m]

Hi Vladimir, Chris,

On 1/29/2016 6:22 AM, Vladimir Kozlov wrote:
> On 1/28/16 12:29 PM, Jamsheed C m wrote:
>>
>>
>> On 1/29/2016 12:15 AM, Christian Thalinger wrote:
>>>     if (count() < cache_size) {
>>>       set_pc_at(count(),addr);
>>>       set_handler_at(count(), handler);
>>>
>>> Shouldn’t we read count() only once into a local variable to rule 
>>> any odd race bugs down the road?
>
> +1. As I understand, Chris is suggesting to do it in addition to 
> storestore barrier.
I have made the suggested change.
http://cr.openjdk.java.net/~thartmann/8143897/webrev.01/

Best Regards,
Jamsheed

>
> Do we have other similar code?
>
> Thanks,
> Vladimir
>
>>
>> write to cache is mutex lock protected. so this code is safe.
>>
>> Issue is seen in weak memory order machines.  lockless read of 
>> exception cache values fails as writes in cache get
>> reordered.
>>
>> Best Regards,
>> Jamsheed
>>>
>>>> On Jan 28, 2016, at 5:16 PM, Jamsheed C m <jamsheed.c.m at oracle.com> 
>>>> wrote:
>>>>
>>>> Hi,
>>>>
>>>> Please review the fix made for issue
>>>>
>>>> bug url: https://bugs.openjdk.java.net/browse/JDK-8143897
>>>> web rev: http://cr.openjdk.java.net/~thartmann/8143897/webrev.00/
>>>>
>>>> Unit tests: As its hard, none
>>>>
>>>> Other tests: jprt.
>>>>
>>>> Description of the issue:
>>>> A valid pc match in exception cache returning an invalid handler 
>>>> makes assert to fail.
>>>> This happens as  ExceptionCache reads are lock free access.
>>>>
>>>> As a fix for this i have put a storestore mem barrier before the 
>>>> count is updated.
>>>>
>>>> Best Regards,
>>>> Jamsheed
>>