RFR: 8320649: C2: Optimize scoped values [v13]

Roland Westrelin roland at openjdk.org
Fri Apr 5 13:37:49 UTC 2024


On Thu, 4 Apr 2024 13:29:34 GMT, Emanuel Peter <epeter at openjdk.org> wrote:

>> src/hotspot/share/opto/loopnode.cpp line 5181:
>> 
>>> 5179: }
>>> 5180: 
>>> 5181: bool PhaseIdealLoop::optimize_scoped_value_get_nodes() {
>> 
>> This is a bit of a monster method, with deep nesting. Hard to read. Can you break it up somehow into smaller methods?
>
> You seem to do an all-vs-all optimization here, right?
> Could you do that in a nested loop, and then just dispatch for all combinations:
> hits-hits
> hits-get
> get-hits
> get-get
> 
> Also: is there a reason for the reverse-order?

Regarding the reverse-order: it makes removing the just processed element easier when it's replaced by a dominating node and so is dead. I added a comment for that.

>> test/hotspot/jtreg/compiler/c2/irTests/TestScopedValue.java line 68:
>> 
>>> 66:                     "testSlowPath1,testSlowPath2,testSlowPath3,testSlowPath4,testSlowPath5,testSlowPath6,testSlowPath7,testSlowPath8,testSlowPath9,testSlowPath10");
>>> 67:             for (String test : tests) {
>>> 68:                 TestFramework.runWithFlags("-XX:+TieredCompilation", "--enable-preview", "-XX:CompileCommand=dontinline,java.lang.ScopedValue::slowGet", "-DTest=" + test);
>> 
>> What is the reason for running each test individually?
>
> Hmm. Profile pollution. But if it is so bad, then won't that be an issue "in the real wold"? Is this test not very artificial?

What I would expect is that if there are only a few uses of ScopedValue, then there's a good chance there's no profile pollution. If there are many and profile is polluted, this PR implements some optimizations that should do a reasonable job.

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/16966#discussion_r1553640775
PR Review Comment: https://git.openjdk.org/jdk/pull/16966#discussion_r1553645825


More information about the hotspot-compiler-dev mailing list