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