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 think I have not made the point clearly enough. The `align` function is used to manipulate the address bits for the byte following the `align()`. This means that wherever the code is copied, the address of that byte should have the appropriate address bit configuration in the copy (as well as the original, of course). Since the current implementation is using the base address of the allocated segment to determine alignment, the only way to ensure the proper bit configuration of the address is to ensure the base address of the newly-allocated segment is aligned identically to the original. I believe this is entirely independent of `MaxVectorSize`, so I don't believe it's appropriate to use this value for address alignment. Using `pc()` fixes the case in the source segment, but will break 50% of the time when the segment is copied with a `CodeEntryAlignment` of 32. I think the bottom line is that `align()` is broken for any value greater than `CodeEntryAlignment`. I can foresee a case where it may be beneficial (from an algorithm perspective) to have large alignment values, like align(256) to simplify pointer arithmetic (for example). All of these proposed changes will not ensure this alignment when a segment is copied. Perhaps the appropriate thing to do is to put an `assert()` in `align()` to fail if the requested alignment cannot be ensured? IMHO, the "right" thing to do is to mark the bytes requiring address alignment and handle the cases on copy. This would add significant complexity, however. ------------- PR: https://git.openjdk.java.net/jdk/pull/5547
