RFR: 8266642: improve ResolvedMethodTable hash function [v2]

[Denghui Dong]

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

> Is there a real benchmark that demonstrates this, rather than a 
> micro-benchmark? I'm just trying to understand under conditions this is 
> a real problem.

Sorry, I don't have a real benchmark yet. 
I think the code snippets I provided before will exist in many current applications that rely on method handles.

> Is the output above from JDK 17 or JDK 11? It seems to show the mangled 
> (well "adorned") name, so shouldn't they map to different hash buckets 
> anyway?

>From JDK 11.
The reason why the name displayed in the log is different is because the external name of the target klass is used (see Method::name_and_sig_as_C_string), and in 11, all java.lang.invoke.LambdaForm$MH have the same name( that's why the slot index are the same).

> I'm not sure it is the right approach to "fix" a problem that doesn't 
> really exist in mainline just so it can be backported to 11u

>From my perspective, I think that this problem still exists in the mainline, but users will hardly write code that causes this problem.

Since this patch will not cause obvious performance problems, I think it is harmless to add it to the main-line.

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

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