On Fri, 17 Sep 2021 14:00:44 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. @asgibbons To me Vladimir Kozlov's suggestion of adding a align64() method calling pc() as you originally proposed looks the best. It meets our purpose and is limited in scope. ------------- PR: https://git.openjdk.java.net/jdk/pull/5547
