<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=utf-8">
<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:Aptos;
panose-1:2 11 0 4 2 2 2 2 2 4;}
/* Style Definitions */
p.MsoNormal, li.MsoNormal, div.MsoNormal
{margin:0cm;
font-size:12.0pt;
font-family:"Aptos",sans-serif;}
a:link, span.MsoHyperlink
{mso-style-priority:99;
color:blue;
text-decoration:underline;}
span.EmailStyle19
{mso-style-type:personal-reply;
font-family:"Aptos",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-CA" link="blue" vlink="purple" style="word-wrap:break-word">
<div class="WordSection1">
<p class="MsoNormal"><span style="font-size:11.0pt">> - Profile/Archive score: I've been thinking that maybe a profile/archive score would be something useful to have at some<o:p></o:p></span></p>
<p class="MsoNormal"><span style="font-size:11.0pt">> point. The goal with such a "score" would be to report back to the user how much information from the archive was<o:p></o:p></span></p>
<p class="MsoNormal"><span style="font-size:11.0pt">> effectively used during a production run so that they have some insight about how "good" was the training run used to<o:p></o:p></span></p>
<p class="MsoNormal"><span style="font-size:11.0pt">> create the archive. The score for an archive could be an [weighted] aggregate of the scores of specific parts of the archive.<o:p></o:p></span></p>
<p class="MsoNormal"><span style="font-size:11.0pt">> We could also use the scores, in the future, if we choose to work on something to "merge" or "combine" multiple archives.<o:p></o:p></span></p>
<p class="MsoNormal"><span style="font-size:11.0pt"><o:p> </o:p></span></p>
<p class="MsoNormal"><span style="font-size:11.0pt">There are two things I can think of that may be interesting to track that shouldn’t be too expensive:<o:p></o:p></span></p>
<p class="MsoNormal"><span style="font-size:11.0pt">- how many of the AOTCache preloaded classes get initialized in a given production run as a proxy for how applicable the preloaded / prelinked class base is<o:p></o:p></span></p>
<p class="MsoNormal"><span style="font-size:11.0pt">- how many of the AOTCache aot’d methods are used in the a given run.<o:p></o:p></span></p>
<p class="MsoNormal"><span style="font-size:11.0pt"><o:p> </o:p></span></p>
<p class="MsoNormal"><span style="font-size:11.0pt">Did you have other thoughts on how such a score could be computed?<br>
<br>
> - Condensers: I've been asked recently about the idea of condensers. As far as I understand there is nothing implemented<o:p></o:p></span></p>
<p class="MsoNormal"><span style="font-size:11.0pt">> on the lines of that idea. Is this something that we still plan to work in the future?<o:p></o:p></span></p>
<p class="MsoNormal"><span style="font-size:11.0pt"><o:p> </o:p></span></p>
<p class="MsoNormal"><span style="font-size:11.0pt">The premain efforts have been our primary area of investigation given the unreasonable effectiveness of training runs. Observing the application and optimizing based on those observations fits naturally with
the rest of the Hotspot design – after all, Hotspot is named for observing programs to find the most profitable areas (“hot spots”) to compile. There are actually a lot overlap between what can be done with the two techniques – for example, I wrote a prototype
to replace the runtime LambdaMetaFactory class generation with statically generated classes but found a long tail of behaviour differences (hidden vs non-hidden classes, stack trace differences, nest members, etc). Training runs can also pre-generate the
lambda classes using the LambdaMetaFactory and doing so avoids that long tail of behaviour differences.<o:p></o:p></span></p>
<p class="MsoNormal"><span style="font-size:11.0pt"><o:p> </o:p></span></p>
<p class="MsoNormal"><span style="font-size:11.0pt">Condensers are an area we may come back to more in the future as there are other problems – class path scanning for one – that can be optimized statically without the behaviour difference bug tail.<o:p></o:p></span></p>
<p class="MsoNormal"><span style="font-size:11.0pt"><o:p> </o:p></span></p>
<p class="MsoNormal"><span style="font-size:11.0pt">--Dan</span><span style="font-size:11.0pt"><o:p></o:p></span></p>
<p class="MsoNormal"><span style="font-size:11.0pt"><o:p> </o:p></span></p>
<div id="mail-editor-reference-message-container">
<div>
<div style="border:none;border-top:solid #B5C4DF 1.0pt;padding:3.0pt 0cm 0cm 0cm">
<p class="MsoNormal" style="mso-margin-top-alt:0cm;margin-right:0cm;margin-bottom:12.0pt;margin-left:36.0pt">
<b><span style="color:black">From: </span></b><span style="color:black">leyden-dev <leyden-dev-retn@openjdk.org> on behalf of Cesar Soares Lucas <Divino.Cesar@microsoft.com><br>
<b>Date: </b>Friday, August 23, 2024 at 6:09</span><span style="font-family:"Arial",sans-serif;color:black"> </span><span style="color:black">PM<br>
<b>To: </b>Leyden-dev Maillist <leyden-dev@openjdk.org><br>
<b>Cc: </b>Brian Stafford <Brian.Stafford@microsoft.com>, Mat Carter <Matthew.Carter@microsoft.com><br>
<b>Subject: </b>Some offhand questions<o:p></o:p></span></p>
</div>
<div>
<p class="MsoNormal" style="margin-left:36.0pt"><span style="font-size:11.0pt">Hello!<br>
<br>
I've a few questions that I'd like to ask your opinion about.<br>
<br>
- Signed Jars: As far as I understand, we currently don't include classes from signed jars in the CDS archive. What is the reason for that? I had the impression that being able to archive such classes would be important given that many .jars are signed?!<br>
<br>
- Profile/Archive score: I've been thinking that maybe a profile/archive score would be something useful to have at some point. The goal with such a "score" would be to report back to the user how much information from the archive was effectively used during
a production run so that they have some insight about how "good" was the training run used to create the archive. The score for an archive could be an [weighted] aggregate of the scores of specific parts of the archive. We could also use the scores, in the
future, if we choose to work on something to "merge" or "combine" multiple archives.<br>
<br>
- Condensers: I've been asked recently about the idea of condensers. As far as I understand there is nothing implemented on the lines of that idea. Is this something that we still plan to work in the future?<br>
<br>
- Recompilation: I've been reviewing the changes in the @premain branch, and I came across this piece of code [1] and was puzzled by it. Why do we recompile the code at every compilation level? There is a lot I still don't understand about the implementation
in premain, but what I was expecting was that at some point in the code we would just "dump" the code cache and that would be our "AOT compiled code".<br>
<br>
<br>
Thanks,<br>
Cesar<br>
<br>
[1] <a href="https://github.com/openjdk/leyden/blob/premain/src/hotspot/share/compiler/precompiler.cpp#L234">
https://github.com/openjdk/leyden/blob/premain/src/hotspot/share/compiler/precompiler.cpp#L234</a><o:p></o:p></span></p>
</div>
</div>
</div>
</div>
</body>
</html>