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

[coleen.phillimore at oracle.com]

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!
Coleen

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
>