Review Request CR#7118743 : Alternative Hashing for String with Hash-based Maps

Rémi Forax forax at
Fri May 25 16:25:49 UTC 2012

On 05/25/2012 04:41 AM, Krystal Mok wrote:
> Hi Mike,
> On Fri, May 25, 2012 at 10:12 AM, Mike Duigou<mike.duigou at>wrote:
>> On May 24 2012, at 16:32 , Vitaly Davidovich wrote:
>>> That's a bit odd as I thought the Klass object in the VM stored
>> something like 7 supers, which includes interfaces (if I'm not mistaken).
>>   I know that instanceof checks against final classes are optimized into a
>> simple cmp against an address, but I'm surprised that a check against an
>> interface for classes in a very shallow type hierarchy is up to x25 slower.
>>   Do you know why that is Mike? Did you ask the compiler guys by chance?
>> I didn't actually look much further into it other than to write a small
>> microbenchmark to make sure it was the instanceof check. I tested a couple
>> of different configs of classes and interfaces and supers. I was able to
>> validate that 'x instanceof String'  was as fast as 'x.getClass() ==
>> String.class' and that other cases were slower. Inheritance checks seemed
>> faster than checks on interfaces. That was enough to tell me that I was on
>> the wrong track with 'x instanceof Hashable' as a way to determine which
>> hash algorithm to use. At least for C2 server compiler.
>> FYI, "x.getClass() == String.class" will be just as fast when 7170463 [1]
> is in.
> @Vitaly
> The fast subtype checking algorithm in HotSpot treats interfaces as
> "secondary supers", which goes through a slow path. The super type display
> in instanceKlass is only for "primary supers", which does not include
> interfaces for instance classes. You may want to check out the details in
> this paper [2].

Also the code of HashMap is used from too many callsites
so the JIT will not be able to use any profiling information.

>> Definition 5:  A class T is a secondary type iff T is an interface or
>> an array of a secondary type. Every type is either a primary
>> type or a secondary type but not both.
> Regards,
> Kris
> [1]:
> [2]:


More information about the core-libs-dev mailing list