RFR(XS) 8249719: MethodHandle performance suffers from bad ResolvedMethodTable hash function
Thomas Stüfe
thomas.stuefe at gmail.com
Sat Jul 25 07:18:38 UTC 2020
Hi, Andrei,
Good find. I played around with a test of generating lots of lambdas and
yes, all the hashes are equal. With your patch invocation time went down by
half (that was for 10000 lambdas).
The test looks fine though the normal way to do this seems to be jcod. I
personally don't care since the test is nice and self contained that way,
but someone from the Oracle runtime group should confirm this is fine
(ccing Coleen).
JDK11 seems to be affected too.
This probably also affects jruby.
+1 from me.
..Thomas
On Fri, Jul 24, 2020 at 4:53 PM Andrei Pangin <andrei.pangin at gmail.com>
wrote:
> Hi,
>
> Please review a small fix to a not-so-small performance issue that we've
> seen when migrating a production application from JDK 8 to JDK 14.
>
> On certain workloads, where Nashorn produces thousands MethodHandles,
> ResolvedMethodTable operations become extremely slow due to degenerate
> hashcode. This patch basically fixes hashcode by including the method
> holder's name in the computation. More details in the bug report.
>
> CR: https://bugs.openjdk.java.net/browse/JDK-8249719
> Webrev: https://cr.openjdk.java.net/~apangin/8249719/webrev/
>
> Tested: tier1-2, hotspot*runtime
>
> I'll be glad if someone could sponsor the patch.
>
> Thank you,
> Andrei Pangin
>
More information about the hotspot-runtime-dev
mailing list