RFR: 8351833: Unexpected increase in live nodes when splitting Phis through MergeMems in PhiNode::Ideal [v3]

[Roberto Castañeda Lozano]

On Thu, 10 Apr 2025 11:39:43 GMT, Daniel Lundén <dlunden at openjdk.org> wrote:

>> test/hotspot/jtreg/compiler/itergvn/TestSplitPhiThroughMergeMem.java line 67:
>> 
>>> 65:             new String("abcdef" + param2);
>>> 66:             new String("ghijklmn" + param1);
>>> 67:             new String("ghijklmn" + param1);
>> 
>> This test illustrates an interesting behavior: C2 generates around 12 Kb of code for this rather infrequent code path (and the frequency can be further reduced without affecting C2's outcome). This seems to contradict C2's general philosophy of focusing the compilation effort (and code cache usage) on hot code. It would be interesting to investigate whether there is an opportunity to make some heuristic more execution-frequency aware here.
>
> Yes, for sure interesting. Let us create a separate RFE to investigate.

I had a closer look at the example and found that the generation of large amounts of cold code is due to two factors:
1. (excessive?) use of `@ForceInline` in [StringConcatHelper](https://github.com/openjdk/jdk/blob/master/src/java.base/share/classes/java/lang/StringConcatHelper.java) and 
2.  generation of fast/path idioms for constructs within the cold inlined code (allocations in particular). 

For 1. we should evaluate whether forced inlining in  `StringConcatHelper` is warranted (in terms of cost/benefits). For 2., I filed [JDK-8354509](https://bugs.openjdk.org/browse/JDK-8354509).

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

PR Review Comment: https://git.openjdk.org/jdk/pull/24325#discussion_r2041728751