optimize KlassInfoTable size to power of 2

[臧琳]

Hi Andrew, 
  Thanks for your comments.
  I think the reason that idiv is issued is that the constant _num_buckets is not used 
directly for the hash idx calculation. It is the _size which is initialized to be _num_buckets.
And I am also puzzling about why the _size is necessary since there is no modification on 
it after initialization.
  I can try use _num_buckets directly to calculate idx and see what is the instruction 
issued, and also do some measurement for comparing. 
  Would you like to give more details about the benefit of using hash table with prime 
size? Thanks!

Cheers,
Lin


-----Original Message-----
From: Andrew Haley [mailto:aph at redhat.com] 
Sent: Monday, December 10, 2018 8:30 PM
To: 臧琳 <zanglin5 at jd.com>; serviceability-dev at openjdk.java.net
Subject: Re: optimize KlassInfoTable size to power of 2

On 12/10/18 6:24 AM, 臧琳 wrote:
>      My observation is that when “jmap histo” iterating objects , the object’s klass
>    is identified and then hash idx in KlassInfoTable’s buckets[] is 
> calculated by mod of _num_bucktes, which would issue a heavy 
> instruction idiv on x86 platform. It means for every object scanned, a 
> idiv instruction is issued, which lag the performance espically when there are large number of objects in heap.

I'm surprised that GCC uses idiv in this case: it has an optimization for constant modulo which doesn't use division. There is sometimes an advantage for using hash tables of prime size. Is it that the size of the table is not a constant that GCC can see?

--
Andrew Haley
Java Platform Lead Engineer
Red Hat UK Ltd. <https://www.redhat.com>
EAC8 43EB D3EF DB98 CC77 2FAD A5CD 6035 332F A671