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

[Daniel Lundén]

On Wed, 23 Apr 2025 08:56:53 GMT, Daniel Lundén <dlunden at openjdk.org> wrote:

>> @dlunde Again: thanks for working on this! It looks like a lot of work, and the existing code was not exactly in the best stlye already 😅  So don't get discouraged by my many comments, a lot of them are small things anyway, and many are just nits.
>
> @eme64 Thanks for the comments, I'll start addressing them soon! I'm certainly not discouraged (rather the opposite), keep the comments coming :slightly_smiling_face:

>@dlunde I responded to a few more issues above at my previous comments. I have not yet looked at the code itself again. I can do that once we have discussed the current topics :)

Thank @eme64! Sure, sounds good.

> But then: why not just increase the test timeout?

I have now reinvestigated (it's been a while) the `java/lang/invoke` tests, and increasing the timeout instead of limiting the number of nodes is indeed a viable (and, I agree, cleaner) option. To investigate, I reset `BigArityTest.java`, `TestCatchExceptionWithVarargs.java`, and `VarargsArrayTest.java` to their current mainline state, and reran testing with many different flag combinations.
- The main issue I encountered earlier on with `BigArityTest.java` was memory consumption, but since I published this PR a `-XX:CompileCommand=memlimit,*.*,0` has been added to the `@run`. Therefore, the current mainline version of this test (with no reduced `MaxNodeLimit`) now passes after this changeset, although it still takes significantly longer to run with `-Xcomp` compared to mainline (due to the additional enabled compilations). `BigArityTest.java` also already has a (very) generous timeout, so it seems expected that this test will take a long time to run.
- `TestCatchExceptionWithVarargs.java` no longer times out. I'm not really sure what changed, but it's now fine to remove the reduced `MaxNodeLimit`. The test still takes longer to run with `-Xcomp` compared to mainline, so we still do the additional compilations.
- `VarargsArrayTest.java` still times out, but setting a more generous timeout works fine. Again, it takes significantly longer to run with `-Xcomp` compared to mainline.

> 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!
>
> Hence, I wonder if we should not already investigate this now, so we are a bit more sure we do not see 40sec compilations in the wild.

Yes, I agree that would be unfortunate. The motivation for investigating further in a follow-up issue is that these tests are artificial and do not really occur in practice. We have run extensive performance testing to justify this. While I would prefer to investigate in a follow-up issue, I don't strongly object to investigate as part of this issue. As I mentioned in my response to @robcasloz earlier, I think what we need is to add bailouts related to interference graph size during register allocation. Permitting compilation with many arguments exposes cases where just bailing out on node count (as we do now) is not sufficient.

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

PR Comment: https://git.openjdk.org/jdk/pull/20404#issuecomment-3004549609