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