RFR: 8297912: HotSpot Style Guide should permit alignas (Second Proposal Attempt) [v2]
Kim Barrett
kbarrett at openjdk.org
Thu Dec 8 16:33:08 UTC 2022
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
More information about the hotspot-dev
mailing list