<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:0in;
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:8.5in 11.0in;
margin:1.0in 1.0in 1.0in 1.0in;}
div.WordSection1
{page:WordSection1;}
--></style>
</head>
<body lang="EN-US" link="blue" vlink="purple" style="word-wrap:break-word">
<div class="WordSection1">
<p class="MsoNormal"><span style="font-size:11.0pt">> > Is the “num allocations tracked” all allocations happening in the methods (including no escape?)
<br>
> Yes, we intercept Parse::do_new() and increment the counter if we register the Object idx to the allocation state.
<br>
><br>
> > “num materializations” the number of (escaping) allocations that you had to rematerialize at least once?<br>
> This counter is the number of materializations. One object may be materialized multiple times in different branches.<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">Got it, thanks.</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>
<p class="MsoNormal"><span style="font-size:11.0pt">> </span><span style="font-size:11.0pt">what you are going to do in your case?<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">In my case nothing happens because the object escapes and also there is no Phi.</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>
<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 0in 0in 0in">
<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">Liu, Xin <xxinliu@amazon.com><br>
<b>Date: </b>Thursday, May 18, 2023 at 2:58 PM<br>
<b>To: </b>Cesar Soares Lucas <Divino.Cesar@microsoft.com>, hotspot-compiler-dev@openjdk.java.net <hotspot-compiler-dev@openjdk.java.net><br>
<b>Subject: </b>Re: Update on PEA in C2 (Episode 3)<o:p></o:p></span></p>
</div>
<div>
<p class="MsoNormal" style="margin-bottom:12.0pt"><span style="font-size:11.0pt">Hi, Cesar,
<br>
> Is the “num allocations tracked” all allocations happening in the methods (including no escape?)
<br>
Yes, we intercept Parse::do_new() and increment the counter if we register the Object idx to the allocation state.
<br>
<br>
> “num materializations” the number of (escaping) allocations that you had to rematerialize at least once?<br>
This counter is the number of materializations. One object may be materialized multiple times in different branches.
<br>
<br>
Eg. We track one object, but num materializations = 3.<br>
Object o = new Object; <br>
If(a) escape(o);<br>
Else if (b) escape(o);<br>
Ese escaped (o); <br>
<br>
<br>
> Do you by any chance have an idea of how many allocations escape inside a control block and aren’t used after escaping – requiring no merge?<br>
<br>
We are not tracking this case. Your example is very similar the ArgEscape case in the microbenchark.
<br>
<a href="https://github.com/navyxliu/jdk/pull/36/files#diff-c96245c7aa8950a261e64f01570331420bf00e76ba1861130f7381458b345f33R76">https://nam06.safelinks.protection.outlook.com/?url=https%3A%2F%2Fgithub.com%2Fnavyxliu%2Fjdk%2Fpull%2F36%2Ffiles%23diff-c96245c7aa8950a261e64f01570331420bf00e76ba1861130f7381458b345f33R76&data=05%7C01%7CDivino.Cesar%40microsoft.com%7Cb9c41a372dfe48f0b37708db57eaf63c%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C638200438900539346%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C3000%7C%7C%7C&sdata=CyV3o7BDLxn6jB%2BbaYabZ0lFF0FN%2BmFy4eFOHCYs56Q%3D&reserved=0</a><br>
<br>
what you are going to do in your case? <br>
<br>
Our scheme is like this. In the nutshell, our PEA materialization splits the lifecycle of an object. Let's say there's an object which will be marked 'Escape' by C2 EA.
<br>
PEA keeps cloning this object at escaping points in flow-sensitive way. After parse, the original object becomes certainly NonEscaped anymore from the perspective of C2 EA.<br>
<br>
Point p = new Point(…); // NonEscaped<br>
if (….) {<br>
Point p' = materialize(p);<br>
method(p');<br>
}<br>
<br>
<br>
We don't clean it up. We just leave this to C2 Optimizer. There are 3 cases:<br>
1. the object is useless. Removed by C2 optimizer. Like this case. <br>
2. As long as the NonEscaped object is 'unque typing', Scalar Replacement will process it.<br>
3. it's NSR. I wish I could leverage your work on this case. <br>
<br>
Thanks,<br>
--lx <br>
<br>
<br>
<br>
<br>
<br>
From: Cesar Soares Lucas <Divino.Cesar@microsoft.com><br>
Date: Thursday, May 18, 2023 at 10:40 AM<br>
To: "Liu, Xin" <xxinliu@amazon.com>, "hotspot-compiler-dev@openjdk.java.net" <hotspot-compiler-dev@openjdk.java.net><br>
Subject: RE: [EXTERNAL]Update on PEA in C2 (Episode 3)<br>
<br>
CAUTION: This email originated from outside of the organization. Do not click links or open attachments unless you can confirm the sender and know the content is safe.<br>
<br>
Hi, Xin Liu.<br>
<br>
Thank you for working on this. I’m glad to see the progress.<br>
<br>
> PEA: num allocations tracked = 24741, num materializations = 16037<br>
<br>
Can you give more details on what these numbers are? Is the “num allocations tracked” all allocations happening in the methods (including no escape?) and “num materializations” the number of (escaping) allocations that you had to rematerialize at least once?<br>
<br>
Do you by any chance have an idea of how many allocations escape inside a control block and aren’t used after escaping – requiring no merge? If that happens often perhaps it’s a low hanging fruit that you could pursue instead of the general PEA problem. I.e.,
something like this:<br>
<br>
Point p = new Point(…);<br>
if (….) {<br>
method(p);<br>
}<br>
<br>
Thanks,<br>
Cesar<br>
<br>
<br>
From: hotspot-compiler-dev <hotspot-compiler-dev-retn@openjdk.org> on behalf of Liu, Xin <xxinliu@amazon.com><br>
Date: Wednesday, May 17, 2023 at 4:48 PM<br>
To: hotspot-compiler-dev@openjdk.java.net <hotspot-compiler-dev@openjdk.java.net><br>
Subject: Update on PEA in C2 (Episode 3)<br>
Hi, <br>
I would like to update what we have done in C2 PEA. <br>
<br>
We manage to compile java.base module with PEA and inliner. It contains 7, 442<br>
classes and 62,210 methods. Here are the number of objects we track and materialize.<br>
PEA: num allocations tracked = 24741, num materializations = 16037<br>
<br>
We also CTW jdk.compiler and java.compiler modules. No compilation error is<br>
found. We fixed those compiler errors mainly by correcting allocation state. <br>
<br>
We verified behavior with one microbenchmark that we ported to JMH. It shows the<br>
allocation rate drops as expected. Because PEA is flow-sensitive, it can allocate<br>
on demand. The allocate rate reduces 75% when the object has 25% chance to<br>
escape (odd = 4); reduce to 1/8 when the object has only 12.5% chance to escape.<br>
<a href="https://github.com/navyxliu/jdk/pull/36">https://nam06.safelinks.protection.outlook.com/?url=https%3A%2F%2Fgithub.com%2Fnavyxliu%2Fjdk%2Fpull%2F36&data=05%7C01%7CDivino.Cesar%40microsoft.com%7Cb9c41a372dfe48f0b37708db57eaf63c%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C638200438900539346%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C3000%7C%7C%7C&sdata=ZWWPdaHYa7o09UATSh3tmXm38zFE31sLER5r%2BahDNP8%3D&reserved=0</a><br>
<br>
Remaining problems:<br>
1. In order to curb complexity, we disable passive materialization for time<br>
being. Passive materialization takes place only at a merging point because<br>
any of predecessor has already materialized the object. We prove that it is<br>
still correct to skip passive materialization. The downside is that we may<br>
have partial redundant allocation because C2 can't guarantee to eliminate<br>
the original object now. Currently, JDK-8287061 is working on this problem. The<br>
patch unravels 'reducible phi nodes' and then the original AllocateNodes are<br>
eliminated by ScalarReplacement. More details can be found here. <br>
<a href="https://gist.github.com/navyxliu/6239ce24f1ae447060302cc8562cbb71?permalink_comment_id=4520588#gistcomment-4520588">https://nam06.safelinks.protection.outlook.com/?url=https%3A%2F%2Fgist.github.com%2Fnavyxliu%2F6239ce24f1ae447060302cc8562cbb71%3Fpermalink_comment_id%3D4520588%23gistcomment-4520588&data=05%7C01%7CDivino.Cesar%40microsoft.com%7Cb9c41a372dfe48f0b37708db57eaf63c%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C638200438900539346%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C3000%7C%7C%7C&sdata=OfOiMyPNNdLeWNmoFeuvWqsbyIkN1yEtLsrXHWK88Ts%3D&reserved=0</a><br>
<br>
If JDK-8287061 processes all reducible phi nodes, PEA will have synergy effect<br>
with it. Our design goal is to punt complex jobs to C2 optimizer. If PEA<br>
introduces severe performance problem, we will revisit 'passive materialization'.
<br>
<br>
2. There are still 400+ runtime errors when we try to run hotspot:tier1<br>
tests. Most of them are from javac. here is what we have so far.<br>
<br>
$make test TEST="hotspot:tier1" CONF=linux-x86_64-server-fastdebug JTREG="VM_OPTIONS=-XX:+UnlockExperimentalVMOptions -XX:+DoPartialEscapeAnalysis"<br>
Test summary<br>
==============================<br>
TEST TOTAL PASS FAIL ERROR<br>
>> jtreg:test/hotspot/jtreg:tier1 2150 1717 145 288 <<<br>
==============================<br>
<br>
Our understanding is that PEA can't guarantee to replace all the old<br>
objects with the new objects in the debug sections of<br>
GraphKit::add_safepoint_edges().<br>
If deoptimization happens, runtime will rematerialize objects based on the<br>
wrong debuginfo. We end up wrong objects then. Our next goal to fix those runtime<br>
errors.<br>
<br>
We post a draft PR for curious audiences. We will port those tests to jtreg once we fix tier1 tests.<br>
<a href="https://github.com/openjdk/jdk/pull/14041">https://nam06.safelinks.protection.outlook.com/?url=https%3A%2F%2Fgithub.com%2Fopenjdk%2Fjdk%2Fpull%2F14041&data=05%7C01%7CDivino.Cesar%40microsoft.com%7Cb9c41a372dfe48f0b37708db57eaf63c%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C638200438900539346%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C3000%7C%7C%7C&sdata=7ukU3FbfcQK8rUZjLS4y%2BUnfSH6tCE0piT82IlV4n3c%3D&reserved=0</a><br>
<br>
thanks,<br>
--lx<o:p></o:p></span></p>
</div>
</div>
</div>
</div>
</body>
</html>