review (XS): 7047491: C1: registers saved incorrectly when calling checkcast_arraycopy stub

[Igor Veresov]

On 5/26/11 12:03 AM, Tom Rodriguez wrote:
> That seems reasonable.  Do we always have stack space for this on x64?  I can't remember how that space is reserved.
>

Hm, I just assumed it's there because previous code used it. Now that I 
look at it I don't even see how it worked in 32bit. The space on stack 
is allocated in java_calling_convention() which is called from 
ArrayCopyStub::emit_code(). So even in 32bit there should be only space 
on stack for 3 out of 5 arguments, yet 5 slots are used. Perhaps we get 
it adjusted but I don't see how...

igor

> tom
>
> tom
>
> On May 25, 2011, at 11:56 PM, Igor Veresov wrote:
>
>> I guess this mail didn't make it. Resending.
>>
>> -------- Original Message --------
>> Subject: review (XS): 7047491: C1: registers saved incorrectly when calling	checkcast_arraycopy stub
>> Date: Mon, 23 May 2011 12:48:50 -0700
>> From: Igor Veresov<igor.veresov at oracle.com>
>> To: hotspot-compiler-dev<hotspot-compiler-dev at openjdk.java.net>
>>
>> Incorrect handling of the registers made runThese fail one of the
>> arraycopy tests on 64bit windows with -d64 -Xcomp -XX:+TieredCompilation.
>>
>> The problem is that when we call the checkcast_arraycopy stub we assume
>> that it abides to C calling convention, but in fact it doesn't, so it
>> can kill the registers containing arguments that are expected later by
>> the slow stub. The easiest solution is to save argument registers before
>> the call and then restore them.
>>
>> Webrev: http://cr.openjdk.java.net/~iveresov/7047491/webrev.00/
>>
>> Tested with JPRT by passing -XX:+TieredCompilation to every test.
>>
>> igor
>