RFR: 8325467: Support methods with many arguments in C2 [v17]

[Emanuel Peter]

On Fri, 25 Apr 2025 17:58:03 GMT, Daniel Lundén <dlunden at openjdk.org> wrote:

>> test/jdk/java/lang/invoke/VarargsArrayTest.java line 46:
>> 
>>> 44:  *                                 -DVarargsArrayTest.MAX_ARITY=255
>>> 45:  *                                 -DVarargsArrayTest.START_ARITY=250
>>> 46:  *                                 VarargsArrayTest
>> 
>> Same here.
>> 
>> But I mean are those timeouts ok with Xcomp? Are we sure that these timeouts are only a test issue and not a product issue?
>
> There is a thread in the PR about this already (difficult to find!), so I'm pasting it below for convenience.
> 
>> @[robcasloz](https://github.com/robcasloz) robcasloz [3 weeks ago](https://github.com/openjdk/jdk/pull/20404#discussion_r2023195229)
> Just checking: these methods that cause C2 to consume an excessive amount of memory were not C2-compilable before the changeset, right?
>> 
>> @[robcasloz](https://github.com/robcasloz) robcasloz [3 weeks ago](https://github.com/openjdk/jdk/pull/20404#discussion_r2023204041)
> Same question for the other java/lang/invoke test changes.
>> 
>> @[dlunde](https://github.com/dlunde) dlunde [3 weeks ago](https://github.com/openjdk/jdk/pull/20404#discussion_r2028661113)
> Yes, correct. No longer bailing out on too many arguments results in a lot more compilations (with -Xcomp) compared to before in these specific tests, which is why I've had to limit the tests with MaxNodeLimits.
>> 
>> That said, I did look into these tests a bit more now after your comment, and there are some peculiar (but artificial) compilations that we no longer bail out on and that we may want to investigate in a future RFE. These compilations each take around 40 seconds (in a release build), are very close to the MaxNodeLimit (80 000 nodes), and spend 99% of the time in the register allocator (in the first round of conservative coalescing, specifically). I analyzed these register allocator runs and it looks like we run into the quadratic time complexity of graph-coloring register allocation, because we have a very large number of nodes to begin with and then the interference graph is additionally very dense (contains a very large number of interferences/edges). We already have bailouts related to node count in the register allocator, but no bailouts for the interference graph size. Perhaps we should consider adding this as part of a separate RFE.
>> 
>> @[robcasloz](https://github.com/robcasloz) robcasloz [3 weeks ago](https://github.com/openjdk/jdk/pull/20404#discussion_r2028671476)
>> > Perhaps we should consider adding this as part of a separate RFE.
>> 
>> This sounds like a good idea, I agree to postpone it to a separate RFE.

Oh I see, you have some comments about why you modify `MaxNodeLimit` in these tests here. It would be nice if you mentioned this information in the PR description! To me, this looks like a possible cause for (compile time) regressions. Imagine, someone has such a method in the startup/warmup of their application. And now this change all of the sudden delays compilation by 40seconds. That would be quite bad!

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

PR Review Comment: https://git.openjdk.org/jdk/pull/20404#discussion_r2158563316