Update on PEA in C2 (Episode 3)

Liu, Xin xxinliu at amazon.com
Wed May 17 23:48:13 UTC 2023


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://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://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://github.com/openjdk/jdk/pull/14041

thanks,
--lx




More information about the hotspot-compiler-dev mailing list