RFR: 8276314: [JVMCI] check alignment of call displacement during code installation

[Doug Simon]

On Tue, 2 Nov 2021 23:50:06 GMT, Tom Rodriguez <never at openjdk.org> wrote:

>> src/hotspot/cpu/x86/jvmciCodeInstaller_x86.cpp line 194:
>> 
>>> 192:       return;
>>> 193:   }
>>> 194:   if (os::is_MP() && !call->is_displacement_aligned()) {
>> 
>> You are checking for `MP` in current era? Why not always require alignment?
>
> I agree.  I think C2 has always aligned and C1 used to check is_MP but no longer does.  Requiring JVMCI compilers to always align seems right, particularly since we don't expose is `is_MP` through JVMCI.  Graal and C1 actually appear to over align the displacement by aligning it to BytesPerWord while C2 always aligns to 4 which is all that is required.  It's odd that alignment check in NativeCall isn't simply `displacement_offset() % 4`.  The existing check implies that it's ok to use a misaligned offset as long as it starts and ends within an 8 byte region but I don't know that that would really work and none of the compilers actually take advantage of it.  That's probably beyond the scope of this PR.  Actually `verify_alignment` checks that it's aligned on BytesPerInt so maybe `is_displacement_aligned` should unify around that definition.

I will remove the `is_MP()` calls.

>while C2 always aligns to 4

I'm having trouble finding where that is done - can you please point it out.

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

PR: https://git.openjdk.java.net/jdk/pull/6218