getting ciInstancKlass for a class that might not be loaded

Deneau, Tom tom.deneau at
Fri Jul 6 13:47:01 PDT 2012

Changed subject line to better reflect what we're discussing here...

Vladimir --

OK, using find_class() I was able to get the ciKlass created (at least in the case
where the AESCrypt class was already loaded) and generate the instanceof Node.

Question: Is there not a way to force the class to load?
Otherwise, it seems like if the class is not loaded yet, we will not be able
to generate the instanceof check which will find cases later on where we 
would call the instrinsic.

I am thinking of a case where the CipherBlockChaining has been called
with one algorithm, say DES, enough times to be compiled, but then later
it is going to be called with AES algorithm and we want that to take the
intrinsic path.  But maybe this is an unusual case that we should not worry about?

-- Tom

-----Original Message-----
From: Vladimir Kozlov [mailto:vladimir.kozlov at] 
Sent: Friday, July 06, 2012 12:30 PM
To: Deneau, Tom
Cc: Krystal Mok; hotspot-compiler-dev at
Subject: Re: x86-64 stub calling convention

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.


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]
> Sent: Friday, July 06, 2012 12:17 AM
> To: Deneau, Tom
> Cc: Vladimir Kozlov; hotspot-compiler-dev at
> 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>  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

More information about the hotspot-compiler-dev mailing list