RFR: 8295146: Clean up native code with newer C/C++ language features [v3]

Kim Barrett kbarrett at openjdk.org
Wed Nov 23 05:02:09 UTC 2022


On Mon, 21 Nov 2022 02:43:12 GMT, Julian Waters <jwaters at openjdk.org> wrote:

> Out of curiosity, is there a way to get the discussion on approving the use of alignas back up? [...]

A PR to address JDK-8252584 would be welcomed by me. Just do the process for
Style Guide changes (see the Style Guide or previous PRs for such). I don't
expect it would be very controversial. I think the only reason it hasn't
already happened is because nobody has gotten around to it, or felt the need
for it.

JDK-8250269 touches a bit more code (mostly in stubGenerator_x86_64 and
macroAssembler_x86_32), but also seems like it should be straightforward.

> > The various MSVC-conditional direct uses of __declspec(align(N)) should probably currently be using ATTRIBUTE_ALIGNED.
> 
> The instances of `__declspec(align())` changed here are in the native libraries written in C, not within HotSpot itself. From what I can see at least HotSpot never uses compiler alignment attributes directly and always strictly sticks to `ATTRIBUTE_ALIGNED` (which is probably a good thing)

You are right that the Windows-conditionalized uses are in non-HotSpot code.
I missed that context when skimming through the changes.  Since Visual Studio
is always C++ (even though the shared files are written as C), using alignas
with appropriate conditionalization in those files should be fine.

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

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


More information about the security-dev mailing list