Benchmarks to check migration impact to j.l.invoke and j.l.reflect.Proxy performance

[Adam Sotona]

Yes, calculation of hash of class internal name from its descriptor without sub-stringing might help to save some CPU, however it must be benchmarked.

Another (a bit more radical) approach in this specific case is to use CP entries as constants instead of the ClassDescs and MethodTypeDescs.
Even more CPU can be saved if the constant CP entries are a part of a constant “template” ClassModel and specific proxy classes are generated as the “template” class transformation.


From: liangchenblue at gmail.com <liangchenblue at gmail.com>
Date: Wednesday, 24 May 2023 6:39
To: Adam Sotona <adam.sotona at oracle.com>
Cc: classfile-api-dev <classfile-api-dev at openjdk.org>, asotona at openjdk.org <asotona at openjdk.org>
Subject: Re: Benchmarks to check migration impact to j.l.invoke and j.l.reflect.Proxy performance
Thank you for the info. I've run the ProxyPerf after edits (removing
obsolete code) and the result doesn't look quite promising. It appears
that the exception handler might be time-consuming.

I've just found Claes Redestad's talk about lambda and bytecode
generation performance: https://youtu.be/3r_tHGtpU7A?t=1921
I think I should perform a debug build one day and discover the impact
of string-related operations. My current assumption is that to find a
corresponding ClassEntry in a constant pool, a ClassDesc's descriptor
string must undergo substring and hashCode, which may be costly, so we
might change ClassEntry's hashing strategy so we can just reuse the
cached hashCode of a ClassDesc's descriptorString easily.

On Tue, May 23, 2023 at 8:38 AM Adam Sotona <adam.sotona at oracle.com> wrote:
>
> Hi,
>
> For benchmarking Proxies I’ve used https://github.com/openjdk/jdk/tree/master/test/micro/org/openjdk/bench/java/lang/reflect/Proxy
>
>
>
> Adam
>
>
>
> From: liangchenblue at gmail.com <liangchenblue at gmail.com>
> Date: Tuesday, 23 May 2023 3:49
> To: classfile-api-dev <classfile-api-dev at openjdk.org>, asotona at openjdk.org <asotona at openjdk.org>
> Subject: Benchmarks to check migration impact to j.l.invoke and j.l.reflect.Proxy performance
>
> Hello Adam,
> Last time, you said that a major obstacle to the migration of Proxy
> and MethodHandle ASM code to Classfile API is the performance
> degradation. I wish you can share how you measured the impact of
> migration, so that I can try for myself and see the performance
> bottlenecks.
>
> Chen Liang
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://mail.openjdk.org/pipermail/classfile-api-dev/attachments/20230524/e487b307/attachment.htm>