x86-64 stub calling convention

Fri Jul 6 06:34:47 PDT 2012

Actually, it can handle intrinsics for other classes as well but it required
small changes in methodOopDesc::klass_id_for_intrinsics()

The problem I am having here is that systemDictionary only supports classes on the bootclasspath.

So I simply need a way to make a ciInstanceKlass for a class that may not have been loaded yet but at the
time we are doing this it's classloader has been defined, etc.

-- Tom

-----Original Message-----
From: Krystal Mok [mailto:rednaxelafx at gmail.com] 
Sent: Friday, July 06, 2012 12:17 AM
To: Deneau, Tom
Cc: Vladimir Kozlov; hotspot-compiler-dev at openjdk.java.net
Subject: Re: x86-64 stub calling convention

HotSpot only supports intrinsics for classes on the bootclasspath (hence loaded by the bootstrap class loader).

- Kris

Sent from my iPad

On 2012-7-6, at 13:01, "Deneau, Tom" <tom.deneau at amd.com> wrote:

> 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
>>>> 
>>>> 
>>> 
>>> 
>> 
>> 
> 
> 