RFR: 8273459: Update code segment alignment to 64 bytes

[Jatin Bhateja]

On Fri, 17 Sep 2021 14:00:44 GMT, Scott Gibbons <github.com+6704669+asgibbons at openjdk.org> wrote:

> 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.

Following code suggests that instr start addresses always honor CodeEntryAlignment.
https://github.com/openjdk/jdk/blob/master/src/hotspot/share/asm/codeBuffer.cpp#L114

Current value of CodeEntryAligment is 32, a 32 byte aligned address is inherently 8, 16 byte aligned but not vice-versa.

Setting this value to 64 will cover cases for 8,16, 32 and 64 byte alignment constraints in stubGenerator_64.cpp. 

Also there are several location in stubGenerator.cpp using __ align(CodeEntryAlignment) and suddenly it will also ensure 64 byte alignment and create internal fragmentation issue, also as Vliadimir pointed out there are handful location which needs 64 byte alignment.  My  suggestion was, if you are attempting it then its scope should be extended only for AVX512 and hence MaxVectorSize usage was suggested since problem of alignment will majorly surface for vector instructions and MaxVectorSize value can be set to 32 even on AVX512 targets, thus its a robust indicator of vector size and associated alignment constraints.

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

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