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

[Roman Kennke]

Any idea what happened here?

Build Details: 2018-10-17-2046474.roman.source
0 Failed Tests
Mach5 Tasks Results Summary

    UNABLE_TO_RUN: 2
    EXECUTED_WITH_FAILURE: 0
    KILLED: 0
    FAILED: 2
    NA: 0
    PASSED: 71
    Build

        1 Failed
            solaris-sparcv9-solaris-sparcv9-build-8 SetupFailedException
in setup...while running 'jib get-src', return value: 10
        1 Not run
            solaris-sparcv9-install-solaris-sparcv9-build-16 Dependency
task failed: mach5...-6686-solaris-sparcv9-solaris-sparcv9-build-8

    Test

        1 Failed

tier1-debug-open_test_hotspot_jtreg_tier1_runtime-linux-x64-debug-51
SetupFailedException in setup...while running 'jib get-src', return
value: 10
        1 Not run

tier1-solaris-sparc-open_test_hotspot_jtreg_tier1_common-solaris-sparcv9-57
Dependency task failed:
mach5...-6686-solaris-sparcv9-solaris-sparcv9-build-8



Roman


Am 17.10.18 um 22:36 schrieb Vladimir Kozlov:
> 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
>>>>>
>>>>
>>

-------------- 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/20181018/2c931c0b/signature-0001.asc>