review (XS): 7047491: C1: registers saved incorrectly when calling checkcast_arraycopy stub
igor.veresov at oracle.com
Thu May 26 01:46:50 PDT 2011
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...
> 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.
More information about the hotspot-compiler-dev