RFR: JDK-8212603: Need to step over GC barriers in Node::eqv_uncast()

Vladimir Kozlov vladimir.kozlov at oracle.com
Wed Oct 17 20:36:38 UTC 2018


Good.

Thanks,
vladimir

On 10/17/18 1:33 PM, Roman Kennke wrote:
> Thanks Vladimir for the review! I moved the method and will push this
> change:
> 
> http://cr.openjdk.java.net/~rkennke/JDK-8212603/webrev.01/
> 
> .. as soon as jdk/submit says 'green' :-)
> 
> Cheers,
> Roman
> 
> Am 17.10.18 um 20:49 schrieb Vladimir Kozlov:
>> Good to me too. I would only suggest to move Node::eqv_uncast() body
>> near Node::uncast() in node.cpp
>>
>> Thanks,
>> Vladimir
>>
>> On 10/17/18 11:39 AM, Erik Österlund wrote:
>>> Hi Roman,
>>>
>>> Looks good.
>>>
>>> Thanks,
>>> /Erik
>>>
>>> On 2018-10-17 19:54, Roman Kennke wrote:
>>>> Node::eqv_uncast() checks if two nodes are equal (equivalent) behind
>>>> casts. It's used in many places concerning lock elimination. The trouble
>>>> is if the actual nodes are behind GC barriers, and we get the same node
>>>> behind two different GC barrier nodes, this would return false negative.
>>>> We have seen a bad case of this with Shenandoah, where lock elimination
>>>> was subtly thrown off by this, which led to eliminated locks not
>>>> re-locked properly during deoptimization.
>>>>
>>>> I propose to also strip any possible GC barriers like this:
>>>>
>>>> http://cr.openjdk.java.net/~rkennke/JDK-8212603/webrev.00/
>>>>
>>>> Testing: hotspot/tier1, will push through jdk/submit in a bit
>>>>
>>>> Roman
>>>>
>>>
> 


More information about the hotspot-compiler-dev mailing list