RFR(XS) 8249719: MethodHandle performance suffers from bad ResolvedMethodTable hash function

coleen.phillimore at oracle.com coleen.phillimore at oracle.com
Sat Jul 25 14:34:22 UTC 2020

Hi Andrei,
This looks good.  Thank you for finding this bug.  And thanks to Volker 
for sponsoring it as well.
Nice to see you on the list, Andrei!

On 7/25/20 3:18 AM, Thomas Stüfe wrote:
> 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 
> <mailto: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