[aarch64-port-dev ] Field too big for insn issue with Shenandoah

[Andrew Haley]

On 09/10/2018 07:11 PM, Roman Kennke wrote:
> Am 10.09.2018 um 20:03 schrieb Andrew Haley:
>> On 09/10/2018 04:11 PM, Roman Kennke wrote:
>>> This only happens when running with Shenandoah. I suspect that the extra
>>> barriers that we emit with Shenandoah make the code too big and the PC
>>> too far away from the constants, but I am not sure.
>>
>> Nice catch! I always knew that this was a theoretical possibility, but
>> I never could find a way to trigger it.
>>
>>> Does anybody have an idea why that happens and how to possibly fix it?
>>
>> I'll have a look. It's going to be very awkward if loads can't reach the
>> constant pool. The load offset is 19 bits, shifted by 2, so that's +/- a
>> megabyte. I don't really believe that any method will generate a megabyte
>> of code, so I suspect that there may be some other reason. Perhaps enabling
>> debug mode just generates too much checking code.
>>
>> Which test was running?
>>
> 
> It was happening with basically any program running under fastdebug + C1
> + Shenandoah. It occured because we tripled NMethodSizeLimit when
> running with Shenandoah to make space for extra code for barriers. And
> we 'fixed' it by leaving that flag alone:
> 
> http://hg.openjdk.java.net/shenandoah/jdk/rev/5d035e4eb822
> 
> You might want to crank up that flag to trigger the bug (if it is one)
> in upstream (no Shenandoah). A proper fix might be to enforce an upper
> bound for that flag that ensures offsets from code can always reach the
> constants.

Mmm. I'm surprised that even multiplying NMethodSizeLimit by 3 blows up
the 1Mb limit. I don't know how that can happen.

-- 
Andrew Haley
Java Platform Lead Engineer
Red Hat UK Ltd. <https://www.redhat.com>
EAC8 43EB D3EF DB98 CC77 2FAD A5CD 6035 332F A671