Caching symbolic descriptors for the constant pool

[Adam Sotona]

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> on behalf of Adam Sotona <adam.sotona at oracle.com>
Date: Tuesday, 25 April 2023 16:25
To: Brian Goetz <brian.goetz 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
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> on behalf of Brian Goetz <brian.goetz at oracle.com>
Date: Tuesday, 25 April 2023 16:12
To: 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
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/b190b13c/attachment.htm>