RFR: JDK-8212603: Need to step over GC barriers in Node::eqv_uncast()
Roman Kennke
rkennke at redhat.com
Wed Oct 17 20:33:19 UTC 2018
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
>>>
>>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 833 bytes
Desc: OpenPGP digital signature
URL: <http://mail.openjdk.java.net/pipermail/hotspot-compiler-dev/attachments/20181017/aaaaadbf/signature.asc>
More information about the hotspot-compiler-dev
mailing list