Caching symbolic descriptors for the constant pool

[Brian Goetz]

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