Caching symbolic descriptors for the constant pool

[Adam Sotona]

To separate Classfile API improvements from https://github.com/openjdk/jdk/pull/10991 I’ve created https://bugs.openjdk.org/browse/JDK-8306842 with following list of improvements (independent on the upcoming Constants API changes):
- Switch over `String` patterns can be replaced with switch over single char in some case to prevent calculation of `String` hash.
- `ClassDesc` and `MethodTypeDesc` symbols can be cached and shared inside relevant CP entries to prevent repeated construction and validation of the symbols.
- `StackMapGenerator` can benefit from the cached symbols to prevent repeated construction and validation of the symbols.
- `StackMapGenerator::getFrameIndexFromOffset` can use binary search for improved performance
- `StackMapGenerator.exceptionTable` can pre-calculate offsets to avoid repeated labels resolutions.
- `StackMapGenerator::processExceptionHandlerTargets` can skip execution for try block bodies when unchanged locals.


Second batch of improvements including use of `ClassDesc::internalName` and other benefits of the improved Constants API can follow.

Thanks,
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 11:06
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

From: classfile-api-dev <classfile-api-dev-retn at openjdk.org> on behalf of liangchenblue at gmail.com <liangchenblue at gmail.com>
Date: Tuesday, 25 April 2023 1:18
To: classfile-api-dev <classfile-api-dev at openjdk.org>
Subject: Caching symbolic descriptors for the constant pool
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


There is definitely a lot to re-consider in the Classfile API implementation to boost performance based on the proposed changes in the Constants API.
I’ve set https://github.com/openjdk/jdk/pull/10991 back to draft. It should first split into one or more Classfile API implementation performance improvements and wait before re-proposing it for review (at least fine tune caching of symbols and StackMapGenerator).

I’m looking forward to see all the improvements merged in one place 😊

Thanks,
Adam

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://mail.openjdk.org/pipermail/classfile-api-dev/attachments/20230425/85b61a4c/attachment-0001.htm>