Request for review 7158800: Improve storage of symbol tables
Coleen Phillimore
coleen.phillimore at oracle.com
Wed Jun 13 05:42:25 PDT 2012
I will change the comment. I think 60 times greater than the expected
length makes more sense. The optimal length for this is actually 3 so
60% greater than 3 is pretty useless.
Thank you for the review!
Coleen
On 6/13/2012 7:46 AM, Frederic Parain wrote:
> Coleen,
>
> Overall changeset looks good, however I have a doubt about the formula
> used to decide if a hashmap is unbalanced:
>
> 180 enum {
> 181 rehash_count = 100,
> 182 rehash_percent = 60 // 60%
> 183 };
>
> 89 // Check to see if the hashtable is unbalanced. The caller set a
> flag to
> 90 // rehash at the next safepoint. If this bucket is 60% greater
> than the
> 91 // expected average bucket length, it's an unbalanced hashtable.
> 92 // This is somewhat an arbitrary heuristic but if one bucket gets to
> 93 // rehash_count which is currently 100, there's probably
> something wrong.
> 94
> 95 bool BasicHashtable::check_rehash_table(int count) {
> 96 assert(table_size() != 0, "underflow");
> 97 if (count >
> (((double)number_of_entries()/(double)table_size())*rehash_percent)) {
> 98 // Set a flag for the next safepoint, which should be at some
> guaranteed
> 99 // safepoint interval.
> 100 return true;
> 101 }
> 102 return false;
> 103 }
>
> Line 97, it seems to me that the test is true when count (the number
> of entries in the bucket) is greater than 60 times the expected average
> bucket length, and not 60% greater, or did I miss something?
>
> Thanks,
>
> Fred
>
> On 06/13/12 05:00 AM, Coleen Phillimore wrote:
>> Summary: Use an alternate version of hashing algorithm for symbol and
>> string tables and after a certain bucket size to improve performance
>>
>> This code rehashes the symbol table and/or string table using the
>> murmur3 hash algorithm, if the buckets become unbalanced.
>>
>> This is the JVM side to the JDK performance improvement in changeset
>> ttp://hg.openjdk.java.net/jdk8/tl/jdk/rev/43bd5ee0205e .
>>
>> open webrev at http://cr.openjdk.java.net/~coleenp/7158800_5/
>>
>> Thanks,
>> Coleen
>
More information about the hotspot-runtime-dev
mailing list