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

[Daniel Lundén]

On Wed, 6 Dec 2023 14:40:30 GMT, Andrew Haley <aph at openjdk.org> wrote:

>> Given the +/-1MB range for `adr`, would it instead be a good idea to limit `-XX:NMethodSizeLimit` to 1MB? Then we would not need the fix at all and could still use `adr`.
>> 
>> Something similar to:
>> 
>> diff --git a/src/hotspot/share/c1/c1_globals.hpp b/src/hotspot/share/c1/c1_globals.hpp
>> index 1c22cf16cfe..e2057d20e59 100644
>> --- a/src/hotspot/share/c1/c1_globals.hpp
>> +++ b/src/hotspot/share/c1/c1_globals.hpp
>> @@ -277,7 +277,7 @@
>>                                                                              \
>>    develop(intx, NMethodSizeLimit, (64*K)*wordSize,                          \
>>            "Maximum size of a compiled method.")                             \
>> -          range(0, max_jint)                                                \
>> +          range(0, 1*M)                                                     \
>>                                                                              \
>>    develop(bool, TraceFPUStack, false,                                       \
>>            "Trace emulation of the FPU stack (intel only)")                  \
>
>> Given the +/-1MB range for `adr`, would it instead be a good idea to limit `-XX:NMethodSizeLimit` to 1MB?
> 
> I guess that would be OK. I'm thinking of extreme scenarios where a method's constant pool is large but the stub code at its end is smaller, in which case an `adr` wouldn't quite reach. But I think that's unlikely.

@theRealAph @TobiHartmann: I've now reverted the fix and instead set an upper bound for `NMethodSizeLimit`. Preliminary testing shows no issues, but I'm also running more tests before integrating.

Requesting a re-review, thanks.

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

PR Comment: https://git.openjdk.org/jdk/pull/16951#issuecomment-1845509302