Caching symbolic descriptors for the constant pool

[Brian Goetz]

Right, that was mostly aimed at other folks who are contributing -- 
"this is the most useful general-purpose bench IMO".

On 4/26/2023 11:45 AM, Adam Sotona wrote:
>
> Unfortunately AdaptNull/SHARED_3does 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
>     <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 <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/77036c7a/attachment-0001.htm>