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
jamsheed.c.m at oracle.com
Tue Feb 9 12:29:49 UTC 2016
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