On Tue, 28 Sep 2021 01:10:53 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. > > Reverted `CodeEntryAlignment` to 32 bytes. Added `align64()` function and > updated references to `align(64)`. > HI @asgibbons, Alignment of JIT sequence for loops work under influence of > -XX:OptoLoopAlignment flag. This is currently set to 16 may be we can change > this to 64 and study the effect on ICache as a separate patch as pointed by > @dean-long. I would be very careful changing loop code alignment. You will introduce a lot of NOP instruction into code to alight it which will be executed. I am fine with experimenting (running SPEC benchmarks) with different `OptoLoopAlignment` values - may be on modern CPUs 16 bytes may not be optimal. But there are a lot of code with small loops in Java which will regress if pre-loop code has a lot of NOPs. > > For stubs a new runtime constant StubCodeEntryAlignment can be added which > determines the start address alignment of stub BufferBlobs. This will limit > the impact of changes also will prevent any unwanted fragmentation issues. May be but what benefit you can get with different alignment for stubs code? > > Your current patch with new align64 macro looks good, it will also restrict > the scope of changes. ------------- PR: https://git.openjdk.java.net/jdk/pull/5547
