RFR(XXS) 8027751: C1 crashes in Weblogic with G1 enabled

[Igor Veresov]

Thanks, Vladimir!

igor

On Nov 4, 2013, at 11:58 AM, Vladimir Kozlov <vladimir.kozlov at oracle.com> wrote:

> On 11/4/13 11:49 AM, Igor Veresov wrote:
>> Something like this?
>> http://cr.openjdk.java.net/~iveresov/8027751/webrev.2/
> 
> Yes, it is good.
> 
> Vladimir
> 
>> 
>> igor
>> 
>> On Nov 4, 2013, at 11:14 AM, Vladimir Kozlov <vladimir.kozlov at oracle.com> wrote:
>> 
>>> Fix is good but you need to rename test and test's directory.
>>> 
>>> Vladimir
>>> 
>>> On 11/4/13 10:57 AM, Igor Veresov wrote:
>>>> Sure. IgorI also insists I add a regression test.
>>>> 
>>>> The updated webrev: http://cr.openjdk.java.net/~iveresov/8027751/webrev.1/
>>>> 
>>>> igor
>>>> 
>>>> 
>>>> On Nov 4, 2013, at 8:52 AM, Vladimir Kozlov <vladimir.kozlov at oracle.com> wrote:
>>>> 
>>>>> Can you move && inside macro to avoid NOT_LP64()?:
>>>>> 
>>>>> LP64_ONLY(&& (opr_type != T_OBJECT))
>>>>> 
>>>>> Thanks,
>>>>> Vladimir
>>>>> 
>>>>> On 11/4/13 12:59 AM, Igor Veresov wrote:
>>>>>> G1 barriers use logical operators (xor) on T_OBJECT mixed with T_LONG or T_INT. The current implementation of logical operations on x86 in C1 doesn't allow for long operands to be on stack. There is a special code in the register allocator that forces long arguments in registers on x86. However T_OBJECT can be spilled just fine, and in that case the xor emission will fail.
>>>>>> 
>>>>>> The shortest fix is to force the allocator to keep operands of type T_OBJECT in registers when doing logical operations (as we do with T_LONG already) on 64bit x86.
>>>>>> 
>>>>>> Webrev: http://cr.openjdk.java.net/~iveresov/8027751/webrev.0/
>>>>>> 
>>>>>> Thanks!
>>>>>> igor
>>>>>> 
>>>> 
>>