Caching symbolic descriptors for the constant pool

[Adam Sotona]

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/679358ec/attachment.htm>