On Thu, 16 Sep 2021 13:52:24 GMT, Scott Gibbons <github.com+6704669+asgibb...@openjdk.org> wrote:
> Change the default code entry alignment to 64 bytes from 32 bytes. This > allows for maintaining proper 64-byte alignment of data within a code > segment, which is required by several AVX-512 instructions. > > I ran into this while implementing Base64 encoding and decoding. Code > segments which were allocated with the address mod 32 == 0 but with the > address mod 64 != 0 would cause the align() macro to misalign. This is > because the align macro aligns to the size of the code segment and not the > offset of the PC. So align(64) would align the PC to a multiple of 64 bytes > from the start of the segment, and not to a pure 64-byte boundary as > requested. Changing the alignment of the segment to 64 bytes fixes the issue. > > I have not seen any measurable difference in either performance or memory > usage with the tests I have run. > > See [this > ](https://mail.openjdk.java.net/pipermail/hotspot-dev/2021-August/054180.html) > article for the discussion thread. I share Dean's concern from the discussion before. `CodeEntryAlignment` is used in a lot of places and we have to be careful about changes to it. I found only 7 cases with `align(64)`: src/hotspot/cpu/x86//stubGenerator_x86_64.cpp: __ align(64); src/hotspot/cpu/x86//stubGenerator_x86_64.cpp: __ align(64); src/hotspot/cpu/x86//stubGenerator_x86_64.cpp: __ align(64); src/hotspot/cpu/x86//stubGenerator_x86_64.cpp: __ align(64); src/hotspot/cpu/x86//stubGenerator_x86_32.cpp: __ align(64); src/hotspot/cpu/x86//stubGenerator_x86_32.cpp: __ align(64); src/hotspot/cpu/x86//stubGenerator_x86_32.cpp: __ align(64); It does not justify such general changes. May suggestion would be to add new `align64()` method to call pc() as you suggested in original proposal. New function may also use `MaxVectorSize` as Jatin proposed if it helps. ------------- Changes requested by kvn (Reviewer). PR: https://git.openjdk.java.net/jdk/pull/5547
