RFR: 8321137: Reconsider ICStub alignment [v2]

[Aleksey Shipilev]

> This continues from #16911. It initially started as performance optimization to compact `ICStubs`, but I think the safety arguments for fitting the `ICStub` per instruction cache line prevails. See bug and previous PR for more gory details. The footprint improvements on some architectures come as side-effect of untying the `ICStub` size from `CodeEntryAlignment` to (sometimes lower) cache line size.
> 
> Note that the size of `ICStub` is important, because `ICBuffer` is small (10K by default), and its depletion causes the `ICBufferFull` safepoint. I would make a (separate) argument to bump the default `ICBuffer` size a bit to make it less important.
> 
> Current patch affects `ICStub` size in different ways on different platforms, since current size is effectively 2x`CodeEntryAlignment` and new size is cache line size:
>  - AArch64: 128 -> 64 bytes :)
>  - x86_64: 64 -> 64 bytes :|
>  - x86_32: 32 -> 64 bytes :(
>  - PPC64: 512 -> 128 bytes :))
>  - S390X: 128 -> 256 bytes :(
>  - ARM: 32 -> 64 bytes :(
>  - Zero: <not applicable, Zero does not use IC stubs>
> 
> Additional testing:
>  - [x] Linux x86_64 server fastdebug, `tier{1,2,3,4}`
>  - [x] Linux AArch64 server fastdebug, `tier{1,2,3,4}`

Aleksey Shipilev has updated the pull request incrementally with one additional commit since the last revision:

  Inline new_ic_stub

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/17277/files
  - new: https://git.openjdk.org/jdk/pull/17277/files/c5c6398d..b0875b50

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=17277&range=01
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=17277&range=00-01

  Stats: 8 lines in 2 files changed: 0 ins; 7 del; 1 mod
  Patch: https://git.openjdk.org/jdk/pull/17277.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/17277/head:pull/17277

PR: https://git.openjdk.org/jdk/pull/17277