[9] RFR(S): 8066763: fatal error "assert(false) failed: unexpected yanked node" in postaloc.cpp:139

[Vladimir Kozlov]

Good.

Thanks,
Vladimir

On 12/11/14 1:49 AM, Tobias Hartmann wrote:
> Thanks, Vladimir.
>
> I renamed the variable to 'in':
>
> http://cr.openjdk.java.net/~thartmann/8066763/webrev.01/
>
> Best,
> Tobias
>
> On 11.12.2014 10:28, Vladimir Kozlov wrote:
>> Looks good but rename local from 'req' (required) to 'in' (input) or 'dead'.
>>
>> Thanks,
>> Vladimir
>>
>> On 12/11/14 1:14 AM, Tobias Hartmann wrote:
>>> Hi,
>>>
>>> please review the following patch.
>>>
>>> Bug: https://bugs.openjdk.java.net/browse/JDK-8066763
>>> Webrev: http://cr.openjdk.java.net/~thartmann/8066763/webrev.00/
>>>
>>> Problem:
>>> A null check for an oop loaded by a LoadNNode (300) consists of a CmpNNode
>>> (388), a BoolNode (356) and a IfNode (357) [1].
>>> After matching, the CmpNNode is replaced by a testN_reg node (56) and a jmpCon
>>> node (55) [2]. With implicit null checks enabled (default), the compiler notices
>>> that the oop is accessed by a nearby loadINode (131) and optimizes the code by
>>> using an implicit null check: Instead of checking the oop explicitly, the
>>> loadINode is moved upwards and executed without a check. Code is added to handle
>>> the SIGSEGV and throw the corresponding NullPointerException [3].
>>>
>>> The problem is that after the optimization the testN_reg node is dead (see [3])
>>> and triggers the assert in the register allocator. With implicit null checks
>>> disabled (-XX:-ImplicitNullChecks) the bug does not appear.
>>>
>>> Solution:
>>> The proposed fix checks for dead input nodes after removing the old compare
>>> node. This removes the dead testN_reg node (see [4]).
>>>
>>> Testing:
>>> - Failing test
>>> - JPRT
>>>
>>> Thanks,
>>> Tobias
>>>
>>> [1] https://bugs.openjdk.java.net/secure/attachment/24158/1_before_matching.png
>>> [2]
>>> https://bugs.openjdk.java.net/secure/attachment/24187/2_global_code_motion.png
>>> [3]
>>> https://bugs.openjdk.java.net/secure/attachment/24159/1_global_code_motion.png
>>> [4]
>>> https://bugs.openjdk.java.net/secure/attachment/24161/3_global_code_motion.png
>>>