RFR(XS): 8080699: Assert failed: Not a Java pointer in JCK test

[Vladimir Kozlov]

Good.

Thanks,
Vladimir

On 5/22/15 12:24 AM, Roland Westrelin wrote:
> Vladimir,
>
>>>>> Should it also return false if in(ArrayCopyNode::Src)->is_top()?
>>>>
>>>> That doesn’t feel right: ArrayCopyNode::may_modify() would decide what to return based on src that it doesn’t modify.
>>>
>>> Okay, returning true in such case would be conservative.
>>>
>>> Should we check dest input for top in CallLeafNode::may_modify()? Do we have other similar places?
>>
>> You’re right checking for top dest in CallLeafNode::may_modify() is safer.
>> I don’t see other similar issues elsewhere in the array copy code.
>
> Here is a webrev with the top check in CallLeafNode::may_modify()?
>
> http://cr.openjdk.java.net/~roland/8080699/webrev.01/
>
> Can I push it?
>
> Roland.
>
>>
>> Roland.
>>
>>
>>>
>>> Thanks,
>>> Vladimir
>>>
>>>> Also, I don’t think src can become top and dest not be top during allocation elimination. If that happens at another time (igvn for instance), this part of the graph is being removed and presumably the compiler will get an other chance to optimize it better.
>>>>
>>>> Roland.
>>>>
>>>>
>>>>
>>>>>
>>>>> thanks,
>>>>> Vladimir
>>>>>
>>>>> On 5/20/15 7:03 AM, Roland Westrelin wrote:
>>>>>> http://cr.openjdk.java.net/~roland/8080699/webrev.00/
>>>>>>
>>>>>> When an arraycopy node is eliminated (for a non escaping allocation), its control, src and dest arguments are set to top and it is no longer connected to the rest of the graph through its fall through outputs. It’s not entirely removed from the graph until the next igvn though, and it can be reached through its exception processing outputs. That’s what happens here and ArrayCopyNode::may_modify() assumes dest, that is top, is an oop.
>>>>>>
>>>>>> Roland.
>>>>>>
>>>>
>>
>