RFR: 8297912: HotSpot Style Guide should permit alignas (Second Proposal Attempt) [v2]

[Kim Barrett]

On Sun, 4 Dec 2022 18:18:00 GMT, Julian Waters <jwaters at openjdk.org> wrote:

>> [8252584](https://bugs.openjdk.org/browse/JDK-8252584) was integrated too early due to a mistake on my part, we should redo it and go through the proper approval process this time
>> 
>> (The changes in this commit are exactly identical to 8252584)
>
> Julian Waters has updated the pull request with a new target base due to a merge or a rebase. The incremental webrev excludes the unrelated changes brought in by the merge/rebase. The pull request contains two additional commits since the last revision:
> 
>  - Merge branch 'openjdk:master' into style
>  - HotSpot Style Guide

A benefit of `alignas` is that the argument can be a type, in which case it's
alignment is used. gcc's `__attribute__((aligned(N)))` requires `N` be the
alignment value. One could obtain that from a type using `alignof(T)` or
`std::alignment_of<T>` (though `alignof` is not yet approved for use in
HotSpot - [JDK-8274400](https://bugs.openjdk.org/browse/JDK-8274400)).

Also, the alternative of using std::aligned_storage or std::aligned_union has
problems - [JDK-8298399](https://bugs.openjdk.org/browse/JDK-8298399).

Another advantage compared to our macro workaround is that this isn't
something that can be optional for a port. Some uses may really require the
alignment request be honored, such as aligning a char[] for use as aligned
storage. If a port doesn't define `ATTRIBUTE_ALIGNED` (so uses the empty
default) then we can't use it for that purpose in shared code. (Note that
globalDefinitions_xlc.hpp does NOT define this macro. That's potentially a
bug.)

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

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