x86-64 stub calling convention

Vladimir Kozlov vladimir.kozlov at oracle.com
Fri Jul 6 10:30:01 PDT 2012 

You can try to use find_klass() assuming that AESCrypt and CipherBlockChaining have the same class loader:

   ciKlass* aklass = tinst->klass()->as_instance_klass()->find_klass(ciSymbol::make("AESCrypt"));
   if (aklass->is_loaded()) {
     ciInstanceKlass* klass_AESCrypt = aklass->as_instance_klass();

where tinst type for CipherBlockChaining class (holder of encrypt() method) is defined in predicate code I sent before. 
You need to check that it is loaded otherwise you can't use it.

Vladimir

On 7/6/12 6:34 AM, Deneau, Tom wrote:
> 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
>>>>>
>>>>>
>>>>
>>>>
>>>
>>>
>>
>>
>
>

More information about the hotspot-compiler-dev mailing list