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

[Vladimir Kozlov]

Please, rerun it.

"No space left on device" when it tried to build on sparcv9 and run tests on linux machine.

Vladimir

On 10/18/18 2:03 AM, Roman Kennke wrote:
> 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
>>>>>>
>>>>>
>>>
>