RFR: 8266642: improve ResolvedMethodTable hash function [v2]

David Holmes dholmes at openjdk.java.net
Mon May 10 05:47:20 UTC 2021


On Fri, 7 May 2021 06:27:25 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:
> 
>   minor adjustment

Hi,

Can you please elaborate on when there are large numbers of classes with the same name? I can see this may help that case but how likely is that case? And what is the impact on other cases as we're now increasing the overhead of the hash computation.

Thanks,
David

test/hotspot/jtreg/runtime/MemberName/ResolvedMethodTableHash.java line 57:

> 55:         byte[] buf = new byte[100];
> 56:         int size = writeClass(buf, "MH$$");
> 57:         Class<?> cls = Unsafe.getUnsafe().defineAnonymousClass(ResolvedMethodTableHash.class, Arrays.copyOf(buf, size), null);

Why do we need to use Unsafe for this rather the public Lookup.defineHiddenClass API?

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

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


More information about the hotspot-dev mailing list