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:a...@redhat.com] Sent: Monday, December 10, 2018 8:30 PM To: 臧琳 <zangl...@jd.com>; serviceability-dev@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
