RFR: 8320682: [AArch64] C1 compilation fails with "Field too big for insn" [v3]

[Daniel Lundén]

On Sat, 9 Dec 2023 14:06:46 GMT, Andrew Haley <aph at openjdk.org> wrote:

>> it's not a single AArch64 issue, though, it's a few places. I have a particular hatred for dead code (or in this case nearly-dead code) paths  that only get exercised in weird test cases. If we insist that  methods may be > 1MB we can't use the compact ADR and LDR forms of relative addressing. To solve this problem, if it is one, we either put up with inefficiencies for no reason other than to make test cases work, or we generate different code especially for such cases. 
>> 
>> We could use something like relaxation, where we first generate methods optimistically then fall back to less-efficient forms, but again that's make-work for test cases.
>> 
>> I know it's "only C1" but every little helps. Efficient systems are made of thousands of tiny optimizations, each one of which is to small to make a measurable difference on its own.
>
> Sorry, that was a bit of a rant. I guess I'm happy that AArch64 will be restricted, if that is the word, to megabyte-long compiled methods, for the aforementioned reasons. Every RISC processor, or at least every processor with fixed-length instructions, will have similar issues.

Making the current assumptions explicit by limiting to 1MB on aarch64 seems like a good solution for the moment. I would advise that we also set a default upper limit for all platforms, to avoid other issues in nearly-dead code paths exercised by huge flag values. See, e.g., [JDK-8320302](https://bugs.openjdk.org/browse/JDK-8320302). I've also seen some other potential issues when doing stress testing.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/16951#discussion_r1422149213