[External] : Re: Caching symbolic descriptors for the constant pool

Adam Sotona adam.sotona at oracle.com
Thu Apr 27 15:07:17 UTC 2023 

I’ve added to the PR a new benchmark:
https://github.com/openjdk/jdk/pull/13671/commits/958174edf6d794096846c879ca81cd2e6a1546f8

It measures repeated transformations rebuilding method bodies (down to the symbols expansion) from already expanded model.
I’ve added shared and unshared CP alternatives (for curiosity), however the unshared is closer to simulation of building from symbols.

Here are results from the actual code base:


Benchmark                      Mode  Cnt      Score     Error  Units

RebuildMethodBodies.shared    thrpt    4  10258.597 ± 383.699  ops/s

RebuildMethodBodies.unshared  thrpt    4   7224.543 ± 256.800  ops/s



And here is visible approx. 22%improvement in both:



Benchmark                      Mode  Cnt      Score      Error  Units

RebuildMethodBodies.shared    thrpt    4  12498.597 ± 309.585  ops/s

RebuildMethodBodies.unshared  thrpt    4   8807.229 ±  167.247  ops/s

I’m looking forward to the numbers after Constants API improvements (cached internal names in ClassDesc and ClassDescs of parameters cached in MethodTypeDescs).
From: liangchenblue at gmail.com <liangchenblue at gmail.com>
Date: Wednesday, 26 April 2023 18:07
To: Brian Goetz <brian.goetz at oracle.com>
Cc: Adam Sotona <adam.sotona at oracle.com>, classfile-api-dev <classfile-api-dev at openjdk.org>
Subject: [External] : Re: 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://urldefense.com/v3/__https://github.com/openjdk/jdk/pull/13671__;!!ACWV5N9M2RV99hQ!IVDau8WQpIsrL_JQ_jJprNpo673-bfPT7Cw0QgrmYLh24m0fmxkAKgMzPtCwY9g0uUa3mmUKVVL2trDA7s6KvQHT$<https://urldefense.com/v3/__https:/github.com/openjdk/jdk/pull/13671__;!!ACWV5N9M2RV99hQ!IVDau8WQpIsrL_JQ_jJprNpo673-bfPT7Cw0QgrmYLh24m0fmxkAKgMzPtCwY9g0uUa3mmUKVVL2trDA7s6KvQHT$>
>
>
>
> 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://urldefense.com/v3/__https://github.com/openjdk/jdk/pull/13598and__;!!ACWV5N9M2RV99hQ!IVDau8WQpIsrL_JQ_jJprNpo673-bfPT7Cw0QgrmYLh24m0fmxkAKgMzPtCwY9g0uUa3mmUKVVL2trDA7qSkfBvJ$<https://urldefense.com/v3/__https:/github.com/openjdk/jdk/pull/13598and__;!!ACWV5N9M2RV99hQ!IVDau8WQpIsrL_JQ_jJprNpo673-bfPT7Cw0QgrmYLh24m0fmxkAKgMzPtCwY9g0uUa3mmUKVVL2trDA7qSkfBvJ$>  8306698
> > https://urldefense.com/v3/__https://github.com/openjdk/jdk/pull/13599__;!!ACWV5N9M2RV99hQ!IVDau8WQpIsrL_JQ_jJprNpo673-bfPT7Cw0QgrmYLh24m0fmxkAKgMzPtCwY9g0uUa3mmUKVVL2trDA7qddDVgO$<https://urldefense.com/v3/__https:/github.com/openjdk/jdk/pull/13599__;!!ACWV5N9M2RV99hQ!IVDau8WQpIsrL_JQ_jJprNpo673-bfPT7Cw0QgrmYLh24m0fmxkAKgMzPtCwY9g0uUa3mmUKVVL2trDA7qddDVgO$> , 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/20230427/b98a7592/attachment-0001.htm>

More information about the classfile-api-dev mailing list