8252584: HotSpot Style Guide should permit alignas #11315
No. Any proposal to permit
It looks like nearly all uses of compiler-specific alignment decorations (such
The only exceptions I found are uses of ZCACHE_ALIGN on class data
I'm assuming you're referring to this when talking about extended alignment? I'm not sure if you mean this warning has to be included together in the Style Guide with alignas
I don't think there's anything we can actually do about ZCACHE_ALIGNED, unfortunately, and the dynamic memory alignment mentioned in 8252584 is still going to be an issue regardless of whichever syntax we use (Utilizing a quick test I cobbled together):
That's the paragraph I referenced. A proposal to permit the use of
Like I said, it probably works to use extended alignment for variables with
Variables with automatic storage duration might also work (I haven't done much
Even for those cases there may be limitations on what values are supported.
Heap allocation of over-aligned types does not work until C++17 (in the sense
Types or data members of types that are never heap allocated (either directly
So I suggest over-aligned types should be forbidden (at least until we move to
The Style Guide should also discuss where the
That dynamic memory alignment is the thing that is fixed by C++17.
I think none of the uses of ZCACHE_ALIGN need the requested alignment. They
I've modified the Style Guide to address some of the issues brought up in the review for the time being
In my opinion it would be helpful to place it at both declaration and definition, just before the type specifier, so it's easier to determine that a variable has a particular alignment without having to check both. Maybe only specifying it at the declaration if that proves to be too troublesome will be enough though
Small side note: Should it also mention that ATTRIBUTE_ALIGNED will be/is deprecated after this style change, and/or that using it is equivalent to
Given that this declaration thingy has no portable meaning beyond max-align, it seems to be actually dangerous to use, for at least some of our use cases in HotSpot. And for the use cases within max-align, the usual workarounds with unions and what-not will do the job, almost always.
In short, this syntax seems like the sort of sugary flaky treat we should avoid. Making our sources less portable in order to make them more beautiful would be a bad bargain.
The ugly-but-reliable way we control stuff like is to concoct some kind of ugly macro, local to HotSpot, that has exactly the semantics that we require, and that is portable.