RFR: 8266642: improve ResolvedMethodTable hash function [v4]

[Denghui Dong]

On Wed, 12 May 2021 10:27:45 GMT, Vladimir Ivanov <vlivanov at openjdk.org> wrote:

> 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);
>   }
> ```

Hi Vladimir,

Thanks for the comment.
I have updated the implementation according to your suggestion.

Thanks,
Denghui

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

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