RFR: 8266642: improve ResolvedMethodTable hash function [v4]

[Vladimir Ivanov]

On Wed, 12 May 2021 05:31:46 GMT, Denghui Dong <ddong at openjdk.org> wrote:

>> JDK-8249719 has fixed the bad hash function problem, however, the performance problem still exists when there are a large number of classes with the same name.
>> Adding the address of the corresponding ClassLoaderData as a factor of hash can solve the problem.
>
> Denghui Dong has updated the pull request incrementally with one additional commit since the last revision:
> 
>   comment

The only way to trigger the problem without VM anonymous classes is to load the same class file by numerous class loaders and then construct `MethodHandle`s for some method in that class. It should be affected by the same problem with the hash function which uses only symbolic info. 

But I'm not sure how much numerous class loaders themselves will stretch the JVM. It can easily make the effects of `ResolvedMethodTable` negligible.
 
Nevertheless, IMO it still makes sense to improve the hash function.


unsigned int method_hash(const Method* method) {
  unsigned int hash = method->klass_name()->identity_hash();
  hash = (hash * 31) ^ method->name()->identity_hash();
  hash = (hash * 31) ^ method->signature()->identity_hash();
  return hash;
}


There's the method address available (`Method*`) which can easily be mixed (as an additional component or as a replacement for any of existing components: method name/signature/holder holder name.

For example, here's how `Symbol::identity_hash()` looks loke: 


class Symbol : public MetaspaceObj {
...
  unsigned identity_hash() const {
    unsigned addr_bits = (unsigned)((uintptr_t)this >> (LogMinObjAlignmentInBytes + 3));
    return ((unsigned)extract_hash(_hash_and_refcount) & 0xffff) |
           ((addr_bits ^ (length() << 8) ^ (( _body[0] << 8) | _body[1])) << 16);
  }

-------------

PR: https://git.openjdk.java.net/jdk/pull/3901