<html xmlns:o="urn:schemas-microsoft-com:office:office" xmlns:w="urn:schemas-microsoft-com:office:word" xmlns:m="http://schemas.microsoft.com/office/2004/12/omml" xmlns="http://www.w3.org/TR/REC-html40">
<head>
<meta http-equiv="Content-Type" content="text/html; charset=Windows-1252">
<meta name="Generator" content="Microsoft Word 15 (filtered medium)">
<style><!--
/* Font Definitions */
@font-face
{font-family:"Cambria Math";
panose-1:2 4 5 3 5 4 6 3 2 4;}
@font-face
{font-family:Calibri;
panose-1:2 15 5 2 2 2 4 3 2 4;}
/* Style Definitions */
p.MsoNormal, li.MsoNormal, div.MsoNormal
{margin:0cm;
font-size:10.0pt;
font-family:"Calibri",sans-serif;}
a:link, span.MsoHyperlink
{mso-style-priority:99;
color:blue;
text-decoration:underline;}
span.EmailStyle19
{mso-style-type:personal-reply;
font-family:"Calibri",sans-serif;
color:windowtext;}
.MsoChpDefault
{mso-style-type:export-only;
font-size:10.0pt;
mso-ligatures:none;}
@page WordSection1
{size:612.0pt 792.0pt;
margin:72.0pt 72.0pt 72.0pt 72.0pt;}
div.WordSection1
{page:WordSection1;}
--></style>
</head>
<body lang="en-CZ" link="blue" vlink="purple" style="word-wrap:break-word">
<div class="WordSection1">
<p class="MsoNormal"><span lang="EN-US" style="font-size:11.0pt;mso-fareast-language:EN-US">I think it perfectly fits to the performance improvements I’m working on.<o:p></o:p></span></p>
<p class="MsoNormal"><span lang="EN-US" style="font-size:11.0pt;mso-fareast-language:EN-US">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.<o:p></o:p></span></p>
<p class="MsoNormal"><span lang="EN-US" style="font-size:11.0pt;mso-fareast-language:EN-US">There is no risk of any growing global caches.<o:p></o:p></span></p>
<p class="MsoNormal"><span lang="EN-US" style="font-size:11.0pt;mso-fareast-language:EN-US"><o:p> </o:p></span></p>
<p class="MsoNormal"><span lang="EN-US" style="font-size:11.0pt;mso-fareast-language:EN-US">If the Constants API will also “cache” internal class name in ClassDesc and ClassDescs of the MethodTypeDesc parameters and return type.
<o:p></o:p></span></p>
<p class="MsoNormal"><span lang="EN-US" style="font-size:11.0pt;mso-fareast-language:EN-US"><o:p> </o:p></span></p>
<p class="MsoNormal"><span lang="EN-US" style="font-size:11.0pt;mso-fareast-language:EN-US">Then we can achieve paths with minimal or no conversions, for example:<o:p></o:p></span></p>
<p class="MsoNormal"><span lang="EN-US" style="font-size:11.0pt;mso-fareast-language:EN-US">ClassDesc -> MethodTypeDesc -> CodeBuilder -> PoolEntry -> InvokeInstruction -> StackMapGenerator -> ClassHierarchyResolver -> ClassDesc -> internal class name -> StackMapGenerator.Type
-> PoolEntry -> BufWriterImpl -> internal class name<o:p></o:p></span></p>
<p class="MsoNormal"><span style="font-size:11.0pt;mso-fareast-language:EN-US"><o:p> </o:p></span></p>
<div style="border:none;border-top:solid #B5C4DF 1.0pt;padding:3.0pt 0cm 0cm 0cm">
<p class="MsoNormal" style="margin-bottom:12.0pt"><b><span style="font-size:12.0pt;color:black">From:
</span></b><span style="font-size:12.0pt;color:black">classfile-api-dev <classfile-api-dev-retn@openjdk.org> on behalf of Brian Goetz <brian.goetz@oracle.com><br>
<b>Date: </b>Tuesday, 25 April 2023 16:12<br>
<b>To: </b>liangchenblue@gmail.com <liangchenblue@gmail.com>, classfile-api-dev <classfile-api-dev@openjdk.org><br>
<b>Subject: </b>Re: Caching symbolic descriptors for the constant pool<o:p></o:p></span></p>
</div>
<div>
<p class="MsoNormal" style="margin-bottom:12.0pt"><span style="font-size:11.0pt">For caching symbols in the Class API, this is fine but we should wait a
<br>
bit. Doing caching raises the question of where the cache lives and how <br>
long it lives; we had some discussions recently about caching for class <br>
hierarchy info, and concluded that we had reached the limits of what we <br>
can do with static entry points. By refactoring the main entry points <br>
(build/parse) to instance methods on a user-controlled "classfile <br>
context" object, we create a logical place and lifetime for caches, of <br>
which we now have two examples.<br>
<br>
Adam currently has a queue of patches he is trying to shepherd in, after <br>
which we will look at refactoring the CHA functionality, after which we <br>
will look at refactoring the "front door", and then that should leave a <br>
natural place to slot in caching of symbolic constants.<br>
<br>
On 4/24/2023 7:18 PM, - wrote:<br>
> First, thanks for the feedback on my cache proposal a few days ago!<br>
> I've prepared two patches under 8306697<br>
> <a href="https://github.com/openjdk/jdk/pull/13598and">https://github.com/openjdk/jdk/pull/13598and</a> 8306698<br>
> <a href="https://github.com/openjdk/jdk/pull/13599">https://github.com/openjdk/jdk/pull/13599</a>, which will hopefully make<br>
> the Constant API more useful with classfiles.<br>
><br>
> I wish to cache symbolic descriptors in classfile API itself. One of<br>
> the prime candidates identified by Adam in his migration of<br>
> java.lang.invoke to classfile API is ClassEntry.asSymbol, which from<br>
> my search, appears to be frequently used in stack map generation. In<br>
> addition, a MethodTypeDesc is passed to stack map generator<br>
> constructor via ofDescriptor (which has slow parsing even after Adam's<br>
> optimization), but the parsing can totally be averted if we can reuse<br>
> the MethodTypeDesc passed in withMethod(). Thus, I wish to add<br>
> accessors like typeSymbol() and cachedTypeSymbol() for MethodInfo to<br>
> speed up StackMapGenerator initialization.<br>
><br>
> In addition, the stack map generator has a custom bitset-based tool to<br>
> split a descriptor on the fly (See<br>
> StackMapGenerator.processInvokeInstructions). I believe they can<br>
> benefit from reusing a parsed MethodTypeDesc as well, especially if<br>
> the invoke instructions were originally built with MethodTypeDesc.<br>
><br>
> Chen Liang<o:p></o:p></span></p>
</div>
</div>
</body>
</html>