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

Tom Rodriguez never at openjdk.java.net
Tue Nov 2 23:55:10 UTC 2021


On Tue, 2 Nov 2021 22:41:47 GMT, Vladimir Kozlov <kvn at openjdk.org> wrote:

>> This PR add verification of code alignment invariants related to x64 call instructions during code installation.
>> This in turn allows a JVMCI compilation that generates a misaligned call to fail gracefully (i.e. bailout) instead of the VM crashing when it checks alignment before patching the displacement of a call instruction.
>
> 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.

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

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


More information about the hotspot-compiler-dev mailing list