[8u20, 9] RFR(S): 8011646 : SEGV in compiled code with loop predication

[Vladimir Kozlov]

On 5/29/14 12:17 PM, Albert wrote:
> John, Vladimir, thanks for your comments.
>
> How shall we proceed with this bug? Is it OK to push this change?
> Shall I file an RFE that suggests to further investigate possible issues
> at the places that Vladimir mentioned?

I think we need to do only point fix in inline_native_hashcode() now and 
file RFE to investigate other cases (including Parse::array_load() as 
Roland pointed). May be find general solution when we have dependency on 
several controls. Actually we already have BUG for this:

https://bugs.openjdk.java.net/browse/JDK-6831314

I can assigned it to you, Albert, if you want.

Thanks,
Vladimir

>
> Best,
> Albert
>
>
> On 05/29/2014 03:29 AM, Vladimir Kozlov wrote:
>> On 5/28/14 4:42 PM, John Rose wrote:
>>> On May 28, 2014, at 2:53 PM, Albert <albert.noll at oracle.com
>>> <mailto:albert.noll at oracle.com>> wrote:
>>>
>>>>> It is only 'Node *' to 'Node* ' change. 'udiffs' show that cleanly.
>>>>>
>>>> Yes, I just put the '*' uniformly to the left side.
>>>
>>> (Which is fine BTW, since the majority usage is "T* x" not "T *x";
>>> https://wiki.openjdk.java.net/display/HotSpot/StyleGuide points out we
>>> do such adjustments.)
>>>
>>> Are there any other places where C2 uses normal IR to access the mark
>>> word of an object, and if so, is a similar bug fix needed there?  If so,
>>> the tricky logic for building the free-standing LoadXNode needs to be
>>> factored into a subroutine.
>>
>> There are several places in macro.cpp in expand_lock_node() and
>> expand_unlock_node() which takes control. Note, LockNode is call node
>> and always has control. I thought about this part yesterday but said
>> nothing because we did not have any problems with that code before.
>> And we need more testing if we remove these control edges.
>>
>> Originally these loads were RAW memory operations and required to have
>> control to prevent skipping safepoints.
>>
>> Vladimir
>>
>>>
>>> — John
>