Caching symbolic descriptors for the constant pool

Wed Apr 26 15:45:58 UTC 2023

Unfortunately  AdaptNull/SHARED_3 does not include symbols conversions and building performance (the use case of ProxyGenerator).
I’ll try to add a benchmark focused on building from symbols.

From: Brian Goetz <brian.goetz at oracle.com>
Date: Wednesday, 26 April 2023 17:19
To: Adam Sotona <adam.sotona at oracle.com>, liangchenblue at gmail.com <liangchenblue at gmail.com>, classfile-api-dev <classfile-api-dev at openjdk.org>
Subject: Re: Caching symbolic descriptors for the constant pool
BTW, I have found the AdaptNull/SHARED_3 benchmark to extremely useful for detecting *overall* regressions/improvements.  (Obviously targeted benchmarks are more useful for targeted problems like this one, but if people are going to run one bench before and after a change, it should be this one.)
On 4/26/2023 11:12 AM, Adam Sotona wrote:
FYI: Here is draft of pull request with initial batch of performance improvements (no API change):
https://github.com/openjdk/jdk/pull/13671

It is branched from PR13478 due to its significant changes in StackMapGenerator.

Here are some first measurable improvements:

Benchmark                     Mode  Cnt       Score       Error  Units
GenerateStackMaps.benchmark  thrpt   10  407931.202 ± 13101.023  ops/s

improved by approx 15% to:

GenerateStackMaps.benchmark  thrpt   10  470826.720 ±  3569.194  ops/s

Adam

From: classfile-api-dev <classfile-api-dev-retn at openjdk.org><mailto:classfile-api-dev-retn at openjdk.org> on behalf of Adam Sotona <adam.sotona at oracle.com><mailto:adam.sotona at oracle.com>
Date: Tuesday, 25 April 2023 16:25
To: Brian Goetz <brian.goetz at oracle.com><mailto:brian.goetz at oracle.com>, liangchenblue at gmail.com<mailto:liangchenblue at gmail.com> <liangchenblue at gmail.com><mailto:liangchenblue at gmail.com>, classfile-api-dev <classfile-api-dev at openjdk.org><mailto:classfile-api-dev at openjdk.org>
Subject: Re: Caching symbolic descriptors for the constant pool
I think it perfectly fits to the performance improvements I’m working on.
The “caching” here means to 1:1 store symbol with PoolEntry after the first request or when the entry has been created from the symbol.
There is no risk of any growing global caches.

If the Constants API will also “cache” internal class name in ClassDesc and ClassDescs of the MethodTypeDesc parameters and return type.

Then we can achieve paths with minimal or no conversions, for example:
ClassDesc -> MethodTypeDesc -> CodeBuilder -> PoolEntry -> InvokeInstruction -> StackMapGenerator -> ClassHierarchyResolver -> ClassDesc -> internal class name -> StackMapGenerator.Type -> PoolEntry -> BufWriterImpl -> internal class name

From: classfile-api-dev <classfile-api-dev-retn at openjdk.org><mailto:classfile-api-dev-retn at openjdk.org> on behalf of Brian Goetz <brian.goetz at oracle.com><mailto:brian.goetz at oracle.com>
Date: Tuesday, 25 April 2023 16:12
To: liangchenblue at gmail.com<mailto:liangchenblue at gmail.com> <liangchenblue at gmail.com><mailto:liangchenblue at gmail.com>, classfile-api-dev <classfile-api-dev at openjdk.org><mailto:classfile-api-dev at openjdk.org>
Subject: Re: Caching symbolic descriptors for the constant pool
For caching symbols in the Class API, this is fine but we should wait a
bit.  Doing caching raises the question of where the cache lives and how
long it lives; we had some discussions recently about caching for class
hierarchy info, and concluded that we had reached the limits of what we
can do with static entry points.  By refactoring the main entry points
(build/parse) to instance methods on a user-controlled "classfile
context" object, we create a logical place and lifetime for caches, of
which we now have two examples.

Adam currently has a queue of patches he is trying to shepherd in, after
which we will look at refactoring the CHA functionality, after which we
will look at refactoring the "front door", and then that should leave a
natural place to slot in caching of symbolic constants.

On 4/24/2023 7:18 PM, - wrote:
> First, thanks for the feedback on my cache proposal a few days ago!
> I've prepared two patches under 8306697
> https://github.com/openjdk/jdk/pull/13598and 8306698
> https://github.com/openjdk/jdk/pull/13599, which will hopefully make
> the Constant API more useful with classfiles.
>
> I wish to cache symbolic descriptors in classfile API itself. One of
> the prime candidates identified by Adam in his migration of
> java.lang.invoke to classfile API is ClassEntry.asSymbol, which from
> my search, appears to be frequently used in stack map generation. In
> addition, a MethodTypeDesc is passed to stack map generator
> constructor via ofDescriptor (which has slow parsing even after Adam's
> optimization), but the parsing can totally be averted if we can reuse
> the MethodTypeDesc passed in withMethod(). Thus, I wish to add
> accessors like typeSymbol() and cachedTypeSymbol() for MethodInfo to
> speed up StackMapGenerator initialization.
>
> In addition, the stack map generator has a custom bitset-based tool to
> split a descriptor on the fly (See
> StackMapGenerator.processInvokeInstructions). I believe they can
> benefit from reusing a parsed MethodTypeDesc as well, especially if
> the invoke instructions were originally built with MethodTypeDesc.
>
> Chen Liang

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://mail.openjdk.org/pipermail/classfile-api-dev/attachments/20230426/b928fc84/attachment.htm>