RFR: 8273459: Update code segment alignment to 64 bytes [v4]

[Jatin Bhateja]

On Tue, 28 Sep 2021 17:31:24 GMT, Scott Gibbons <github.com+6704669+asgibbons at 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.
>
> Scott Gibbons has updated the pull request incrementally with two additional commits since the last revision:
> 
>  - Merge branch 'asgibbons-align-fix' of https://github.com/asgibbons/jdk into asgibbons-align-fix
>  - Revert .gitignore. Add comments and assert in align().

.

> > 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?
> 
It was an alternative to creating a different align64 macro in anticipation that we may introduce more stubs / code section constants which may give better performance if aligned to 64 byte boundary for wide vector targets like AVX512. New flag is specific to stubs thus has  restrictive scope but at the same time parameterizable and can have different values for targets. 

As you pointed out currently there are handful of places where guaranteed 64 byte alignment is desired so current approach looks good.

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