Update on PEA in C2 (Episode 3)

Thu May 25 21:04:29 UTC 2023

> > Is the “num allocations tracked” all allocations happening in the methods (including no escape?)
> Yes, we intercept Parse::do_new() and increment the counter if we register the Object idx to the allocation state.
>
> > “num materializations” the number of (escaping) allocations that you had to rematerialize at least once?
> This counter is the number of materializations. One object may be materialized multiple times in different branches.

Got it, thanks.

> what you are going to do in your case?

In my case nothing happens because the object escapes and also there is no Phi.

From: Liu, Xin <xxinliu at amazon.com>
Date: Thursday, May 18, 2023 at 2:58 PM
To: Cesar Soares Lucas <Divino.Cesar at microsoft.com>, hotspot-compiler-dev at openjdk.java.net <hotspot-compiler-dev at openjdk.java.net>
Subject: Re: Update on PEA in C2 (Episode 3)
Hi, Cesar,
> Is the “num allocations tracked” all allocations happening in the methods (including no escape?)
Yes, we intercept Parse::do_new() and increment the counter if we register the Object idx to the allocation state.

> “num materializations” the number of (escaping) allocations that you had to rematerialize at least once?
This counter is the number of materializations. One object may be materialized multiple times in different branches.

Eg. We track one object, but num materializations = 3.
Object o = new Object;
If(a) escape(o);
Else if (b) escape(o);
Ese escaped (o);

> 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?

We are not tracking this case.  Your example is very similar the ArgEscape case in the microbenchark.
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<https://github.com/navyxliu/jdk/pull/36/files#diff-c96245c7aa8950a261e64f01570331420bf00e76ba1861130f7381458b345f33R76>

what you are going to do in your case?

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.
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.

Point p = new Point(…); // NonEscaped
if (….) {
   Point p' = materialize(p);
   method(p');
}

We don't clean it up. We just leave this to C2 Optimizer. There are 3 cases:
1. the object is useless.  Removed by C2 optimizer. Like this case.
2. As long as the NonEscaped object is 'unque typing', Scalar Replacement will process it.
3. it's NSR. I wish I could leverage your work on this case.

Thanks,
--lx

From: Cesar Soares Lucas <Divino.Cesar at microsoft.com>
Date: Thursday, May 18, 2023 at 10:40 AM
To: "Liu, Xin" <xxinliu at amazon.com>, "hotspot-compiler-dev at openjdk.java.net" <hotspot-compiler-dev at openjdk.java.net>
Subject: RE: [EXTERNAL]Update on PEA in C2 (Episode 3)

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.

Hi, Xin Liu.

Thank you for working on this. I’m glad to see the progress.

> PEA: num allocations tracked = 24741, num materializations = 16037

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?

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:

Point p = new Point(…);
if (….) {
   method(p);
}

Thanks,
Cesar

From: hotspot-compiler-dev <hotspot-compiler-dev-retn at openjdk.org> on behalf of Liu, Xin <xxinliu at amazon.com>
Date: Wednesday, May 17, 2023 at 4:48 PM
To: hotspot-compiler-dev at openjdk.java.net <hotspot-compiler-dev at openjdk.java.net>
Subject: Update on PEA in C2 (Episode 3)
Hi,
I would like to update what we have done in C2 PEA.

We manage to compile java.base module with PEA and inliner. It contains 7, 442
classes and 62,210 methods. Here are the number of objects we track and materialize.
PEA: num allocations tracked = 24741, num materializations = 16037

We also CTW jdk.compiler and java.compiler modules. No compilation error is
found. We fixed those compiler errors mainly by correcting allocation state.

We verified behavior with one microbenchmark that we ported to JMH. It shows the
allocation rate drops as expected. Because PEA is flow-sensitive, it can allocate
on demand. The allocate rate reduces 75% when the object has 25% chance to
escape (odd = 4); reduce to 1/8 when the object has only 12.5% chance to escape.
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<https://github.com/navyxliu/jdk/pull/36>

Remaining problems:
1. In order to curb complexity, we disable passive materialization for time
being. Passive materialization takes place only at a merging point because
any of predecessor has already materialized the object. We prove that it is
still correct to skip passive materialization. The downside is that we may
have partial redundant allocation because C2 can't guarantee to eliminate
the original object now. Currently, JDK-8287061 is working on this problem. The
patch unravels 'reducible phi nodes' and then the original AllocateNodes are
eliminated by ScalarReplacement. More details can be found here.
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<https://gist.github.com/navyxliu/6239ce24f1ae447060302cc8562cbb71?permalink_comment_id=4520588#gistcomment-4520588>

If JDK-8287061 processes all reducible phi nodes, PEA will have synergy effect
with it. Our design goal is to punt complex jobs to C2 optimizer. If PEA
introduces severe performance problem, we will revisit 'passive materialization'.

2. There are still 400+ runtime errors when we try to run hotspot:tier1
tests. Most of them are from javac. here is what we have so far.

$make test TEST="hotspot:tier1"  CONF=linux-x86_64-server-fastdebug JTREG="VM_OPTIONS=-XX:+UnlockExperimentalVMOptions -XX:+DoPartialEscapeAnalysis"
Test summary
==============================
   TEST                                              TOTAL  PASS  FAIL ERROR
>> jtreg:test/hotspot/jtreg:tier1                     2150  1717   145   288 <<
==============================

Our understanding is that PEA can't guarantee to replace all the old
objects with the new objects in the debug sections of
GraphKit::add_safepoint_edges().
If deoptimization happens, runtime will rematerialize objects based on the
wrong debuginfo. We end up wrong objects then. Our next goal to fix those runtime
errors.

We post a draft PR for curious audiences.  We will port those tests to jtreg once we fix tier1 tests.
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<https://github.com/openjdk/jdk/pull/14041>

thanks,
--lx
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://mail.openjdk.org/pipermail/hotspot-compiler-dev/attachments/20230525/3e053f82/attachment-0001.htm>