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

Dean Long dean.long at oracle.com
Wed Feb 10 07:25:29 UTC 2016


OK thanks.

dl

On 2/9/2016 4:29 AM, Jamsheed C m wrote:
>
> On 2/9/2016 4:49 AM, Dean Long wrote:
>> Jamsheed, it just occurred to me, why don't we need a LoadLoad 
>> barrier when we do the lock-free reads?
> There is data dependence in ExceptionCache read code.
>
> Best Regards,
> Jamsheed
>>
>> dl
>>
>> On 2/4/2016 1:04 AM, Jamsheed C m wrote:
>>> Thanks Vladimir.
>>>
>>> Best Regards,
>>> Jamsheed
>>>
>>> On 2/3/2016 11:31 PM, Vladimir Kozlov wrote:
>>>> Looks good.
>>>>
>>>> Thanks,
>>>> Vladimir
>>>>
>>>> On 2/3/16 1:56 AM, Jamsheed C m wrote:
>>>>> 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
>>>>>>>
>>>>>
>>>
>>
>



More information about the hotspot-compiler-dev mailing list