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

Daniel Lundén dlunden at openjdk.org
Fri Apr 4 11:50:03 UTC 2025


On Tue, 1 Apr 2025 16:35:08 GMT, Roberto Castañeda Lozano <rcastanedalo at openjdk.org> wrote:

>> test/jdk/java/lang/invoke/BigArityTest.java line 32:
>> 
>>> 30:  *            (1) have a large number of parameters, and
>>> 31:  *            (2) use JSR292 methods internally (which increases the
>>> 32:  *                MaxNodeLimit with a factor of 3)
>> 
>> Just checking: these methods that cause C2 to consume an excessive amount of memory were not C2-compilable before the changeset, right?
>
> Same question for the other `java/lang/invoke` test changes.

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 `MaxNodeLimit`s.

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.

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

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


More information about the hotspot-compiler-dev mailing list