Caching symbolic descriptors for the constant pool

[-]

I've been using Write/jdkTree as a reference, for it has an asm
baseline that can calibrate between runs and most JDK usages are
write-oriented. If we can run AdaptNull/SHARED_3 with an ASM_1 as a
baseline, it would be more convincing as well.

On Wed, Apr 26, 2023 at 10:47 AM Brian Goetz <brian.goetz at oracle.com> wrote:
>
> 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_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> 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
>
>
>
>