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

[Andrei Pangin]

Hi Volker,

Many thanks for the review and for your willingness to sponsor the change.

The test runs 4-5 seconds on my laptop with the fix, and about 35 minutes
without. Even on ARM32 (Raspberry Pi) it takes 22 seconds, far less than
the timeout. Seems acceptable to me. If not - just let me know, and I'll
change the test to manual.

Andrei

пт, 24 июл. 2020 г. в 21:51, Volker Simonis <volker.simonis at gmail.com>:

> Hi Andrei,
>
> nice finding :)
>
> I think your fix looks good and I'm happy to sponsor your change once
> we get a second review.
>
> I only have a question about your test. How long does it usually run
> before and after your fix? Just trying to understand if it is stable
> enough in cases where a test machine might be overloaded or if we
> should rather make it a manual test.
>
> Thank you and best regards,
> Volker
>
> On Fri, Jul 24, 2020 at 4:54 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
>