Caching symbolic descriptors for the constant pool

[Brian Goetz]

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> 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/f727a803/attachment-0001.htm>