Request for review 7158800: Improve storage of symbol tables

[Coleen Phillimore]

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
>