RFR: 8339573: Update CodeCacheSegmentSize and CodeEntryAlignment for ARM [v3]

[Boris Ulasevich]

On Wed, 9 Oct 2024 14:58:01 GMT, Boris Ulasevich <bulasevich at openjdk.org> wrote:

>> This benchmark certainly has some limitations as nops are special and can be discarded and having the 64B alignment means the core can quickly fetch and throw away as many nops as possible. I'm not sure that it's particularly representative of a real output and the benefits that code density can bring here.
>
> The behavior remains unchanged when replacing the NOP with an ADD x1,x1,x1 instruction. That said, I fully agree with you that the benchmark is peculiar, and the result doesn't necessarily indicate whether the platform is sensitive to code entry alignment. Additionally, I'd like to point out that on the same N1 platform, EEMBC's CoreMark benchmark runs 0.07% faster (a small difference, I know) on G2 when built with -falign-functions=64 compared to -falign-functions=16, with the result for -falign-functions=32 falling in between. This makes me doubt that CodeEntryAlignment=16/32 is reasonable for N1.
> 
> Let me ask Vladimir if it is possible to check the performance with CodeEntryAlignment=32 setting.

Dear @vnkozlov,
Sorry for bothering you. Is it possible to check if CodeEntryAlignment=32 setting causes the regression on Ampere system with the internal benchmark?

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

PR Review Comment: https://git.openjdk.org/jdk/pull/20864#discussion_r1793687533