RFR: 8332724: x86 MacroAssembler may over-align code [v2]

[Vladimir Kozlov]

On Thu, 23 May 2024 09:16:22 GMT, Daniel Jeliński <djelinski at openjdk.org> wrote:

>> The methods align32 and align64 are supposed to align the next instruction to the next 32 or 64 byte boundary using the minimum number of NOP bytes. However, when the target represented as a 32bit signed int is negative, the instructions generate 32 or 64 NOP bytes too many. This was observed in `jbyte_disjoint_arraycopy_avx3` on a Linux machine, where a single align32 invocation generated 63 bytes of NOPs.
>> 
>> This PR addresses the problem by using bit operations to calculate the required number of bytes.
>> 
>> Tier1-3 tests passed.
>> 
>> On a side note, `align64` and `align32` instructions were meant for aligning data for use with zmm / ymm loads, but nowadays they are frequently used in places where `align(CodeEntryAlignment)` or `align(OptoLoopAlignment)` would be more appropriate. I can address that in a separate PR if you think it's worth fixing.
>
> Daniel Jeliński has updated the pull request incrementally with two additional commits since the last revision:
> 
>  - Explicit typecasts
>  - Change to unsigned instead

GHA x86-32 build issue:

/work/jdk/jdk/src/hotspot/cpu/x86/macroAssembler_x86.cpp: In member function ‘void MacroAssembler::align(uint)’:
/work/jdk/jdk/src/hotspot/cpu/x86/macroAssembler_x86.cpp:1162:18: error: comparison of integer expressions of different signedness: ‘uint’ {aka ‘unsigned int’} and ‘intx’ {aka ‘int’} [-Werror=sign-compare]
 1162 |   assert(modulus <= CodeEntryAlignment, "Alignment must be <= CodeEntryAlignment");
      |          ~~~~~~~~^~~~~~~~~~~~~~~~~~~~~

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

PR Comment: https://git.openjdk.org/jdk/pull/19353#issuecomment-2127656170