x86-64 stub calling convention

[Deneau, Tom]

Hi Vladimir --

My earlier statement that this new code was all working well was premature.
I had forgotten to set the is_predicted flag for these routines so it was
not generating the predicated test code.

When I turned that on, I hit the following problem:
  ciInstanceKlass* klass_AESCrypt = env()->AESCrypt_klass();

always returns a null class even though it is defined in SystemDictionary.hpp;
I had followed the pattern you used for your Foo entry in SystemDictionary

  template(AESCrypt_klass,               com_sun_crypto_provider_aescrypt, Opt)  \

Changing Opt to Pre resulted in an immediate error:
  java/lang/NoClassDefFoundError: com/sun/crypto/provider/AESCrypt

Is this perhaps because it is not part of rt.jar and uses a different classLoader?

-- Tom

-----Original Message-----
From: Deneau, Tom 
Sent: Monday, July 02, 2012 3:01 PM
To: 'Vladimir Kozlov'
Cc: Krystal Mok; hotspot-compiler-dev at openjdk.java.net
Subject: RE: x86-64 stub calling convention

I am trying to understand the stub setup on windows x64.
(I have code that is working OK on linux x64).

Trying to understand the need for setup_arg_regs() and restore_arg_regs().
It seems like these only needed if you use explicit register names
in the interior of your stub routine, so you need to have the incoming args map
the same way on windows and linux.

But if I have 4 or fewer incoming integer register arguments and I am willing to use c_arg0, c_arg1, etc,
does that mean I can avoid these calls altogether?

-- Tom


-----Original Message-----
From: Vladimir Kozlov [mailto:vladimir.kozlov at oracle.com] 
Sent: Sunday, July 01, 2012 6:45 PM
To: Deneau, Tom
Cc: Krystal Mok; hotspot-compiler-dev at openjdk.java.net
Subject: Re: x86-64 stub calling convention

It is only used in 32-bit VM to avoid additional code to handle x87 FPU stack around the call to a method which does not 
use FPU. In 64-bit VM it is NOP. Look on mach nodes definitions for CallLeaf and CallLeafNoFP in .ad files. So in your 
case you can set RC_NO_FP flag since you don't use FPU.

Vladimir

On 7/1/12 2:48 PM, Deneau, Tom wrote:
> A related question...
>
> In what cases can the flag bit RC_NO_FP be set when used with make_runtime_call?
> Can it be set when xmm registers are used, but they are only used for integer operations?
>
> -- Tom
>
>
> -----Original Message-----
> From: Vladimir Kozlov [mailto:vladimir.kozlov at oracle.com]
> Sent: Saturday, June 30, 2012 9:35 PM
> To: Deneau, Tom
> Cc: Krystal Mok; hotspot-compiler-dev at openjdk.java.net
> Subject: Re: x86-64 stub calling convention
>
> Currently we use CallRuntime nodes for calling stubs and we use it for calls into runtime (C compiled code) that is why
> it uses C calling convention. We have RFE to create special calling convention for stubs to pass arguments in registers
> even in 32-bit VM but we never had time to do it.
>
> Vladimir
>
> On 6/30/12 7:08 PM, Deneau, Tom wrote:
>> OK, thanks, Vladimir.
>> Is there a good reason for using the OS's C calling convention for stubs?
>> (as opposed to, say, using whatever makes the most sense for Java).
>>
>> -- Tom
>>
>>
>> -----Original Message-----
>> From: Vladimir Kozlov [mailto:vladimir.kozlov at oracle.com]
>> Sent: Friday, June 29, 2012 10:46 PM
>> To: Krystal Mok
>> Cc: Deneau, Tom; hotspot-compiler-dev at openjdk.java.net
>> Subject: Re: x86-64 stub calling convention
>>
>> I was not right that you can use all XMM registers. On windows64 only xmm0-xmm5 are available free, the rest are SOE
>> (save on entry). For stabs calls we use C calling convention. It is described in .ad file where XMM registers are
>> defined (second parameter):
>>
>> // Linux ABI:   No register preserved across function calls
>> //              XMM0-XMM7 might hold parameters
>> // Windows ABI: XMM6-XMM15 preserved across function calls
>> //              XMM0-XMM3 might hold parameters
>>
>> reg_def XMM5   (SOC, SOC, Op_RegF,  5, xmm5->as_VMReg());
>> reg_def XMM5_H (SOC, SOC, Op_RegF,  5, xmm5->as_VMReg()->next());
>>
>> #ifdef _WIN64
>>
>> reg_def XMM6   (SOC, SOE, Op_RegF,  6, xmm6->as_VMReg());
>> reg_def XMM6_H (SOC, SOE, Op_RegF,  6, xmm6->as_VMReg()->next());
>> ...
>>
>> #else
>>
>> reg_def XMM6   (SOC, SOC, Op_RegF,  6, xmm6->as_VMReg());
>> reg_def XMM6_H (SOC, SOC, Op_RegF,  6, xmm6->as_VMReg()->next());
>>
>> Vladimir
>>
>> On 6/29/12 7:25 PM, Krystal Mok wrote:
>>> Hi Tom,
>>>
>>> This is something I'd like to get an answer to, too. I did see in a comment in one of the older changes [1][2] that:
>>>
>>> +       // Spill because stubs can use any register they like and it's
>>> +       // easier to restore just those that we care about.
>>>
>>> Which doesn't really sound reassuring...
>>>
>>> - Kris
>>>
>>> [1]: http://hg.openjdk.java.net/hsx/hotspot-comp/hotspot/rev/28263a73ebfb
>>> [2]: http://mail.openjdk.java.net/pipermail/hotspot-compiler-dev/2011-May/005623.html
>>>
>>> On Sat, Jun 30, 2012 at 9:27 AM, Deneau, Tom<tom.deneau at amd.com<mailto:tom.deneau at amd.com>>   wrote:
>>>
>>>       Hi --
>>>
>>>       Can someone point me to the x86-64 calling convention for stubs created
>>>       by stubGenerator?  In particular, which xmm registers if any must be preserved
>>>       and which are volatile.
>>>
>>>       -- Tom Deneau
>>>
>>>
>>
>>
>
>