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

2022-11-29 Thread Julian Waters
On Wed, 23 Nov 2022 04:58:38 GMT, Kim Barrett wrote: >> Out of curiosity, is there a way to get the discussion on approving the use >> of alignas back up? I've read through 8250269 briefly and unlike the issues >> that come with C++ attributes, alignas looks relatively straightforward to >>

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

2022-11-29 Thread David Holmes
On Tue, 29 Nov 2022 17:07:02 GMT, Julian Waters wrote: >> Digging into this some more, the friend declaration exists to provide access >> to the private `os::win32::enum Ept`. >> >> One obvious and cheap solution to that would be to make that enum public. I >> think that would be an

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

2022-11-29 Thread Julian Waters
On Wed, 23 Nov 2022 21:36:24 GMT, Kim Barrett wrote: >> I think the problem here is the friend declaration, which doesn't look like >> it's needed and could be deleted. > > Digging into this some more, the friend declaration exists to provide access > to the private `os::win32::enum Ept`. > >

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

2022-11-23 Thread Kim Barrett
On Wed, 23 Nov 2022 05:22:10 GMT, Kim Barrett wrote: >> It's to avoid redefining the linkage as static in os_windows.cpp (where it's >> implemented) after an extern declaration (inside the class), which is >> forbidden by C++11: >> >>> The linkages implied by successive declarations for a

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

2022-11-22 Thread Kim Barrett
On Mon, 14 Nov 2022 12:20:54 GMT, Julian Waters wrote: >> Sorry my eyes must be playing tricks on me. ?? >> >> Why did you need to add this here? > > It's to avoid redefining the linkage as static in os_windows.cpp (where it's > implemented) after an extern declaration (inside the class),

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

2022-11-22 Thread Kim Barrett
On Mon, 21 Nov 2022 02:43:12 GMT, Julian Waters 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

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

2022-11-20 Thread Julian Waters
On Tue, 15 Nov 2022 06:33:00 GMT, Kim Barrett wrote: >> Julian Waters has updated the pull request incrementally with one additional >> commit since the last revision: >> >> Revert to using simpler solution similar to the original 8274980 > > src/hotspot/share/utilities/globalDefinitions.hpp

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

2022-11-15 Thread Coleen Phillimore
On Mon, 14 Nov 2022 16:12:48 GMT, Julian Waters wrote: >> After [JDK-8292008](https://bugs.openjdk.org/browse/JDK-8292008) and >> [JDK-8247283](https://bugs.openjdk.org/browse/JDK-8247283), some C and C++ >> code across the JDK can be replaced and simplified with cleaner language >> features

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

2022-11-15 Thread Julian Waters
On Mon, 14 Nov 2022 13:06:28 GMT, Kim Barrett wrote: >> Yep, just something that C++ does a little neater, at least in my view > > We (the HotSpot Group) have not discussed or approved the use of the new C++ > attribute syntax, whether for standard attributes or compiler-specific ones. > That

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

2022-11-15 Thread Julian Waters
On Tue, 15 Nov 2022 06:12:52 GMT, Kim Barrett wrote: >> Reverted to use the original, less intrusive solution from >> [8274980](https://github.com/openjdk/jdk/pull/11081/commits/83ed3deb29d7344bbc95a3831f2388d077bc59e9) >> that initially could not work with the older Visual C++ compiler (With

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

2022-11-14 Thread Kim Barrett
On Mon, 14 Nov 2022 08:02:49 GMT, David Holmes wrote: >> Yep, it was renamed since the file is also named VISCPP, and I felt that >> matching the names was a good style change > > I think it is the file that has the "bad" name in this case. :( But okay. I also think the macro name should be

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

2022-11-14 Thread Kim Barrett
On Tue, 15 Nov 2022 00:49:59 GMT, Julian Waters wrote: >> make/hotspot/lib/CompileJvm.gmk line 67: >> >>> 65: # Hotspot cannot handle an empty build number >>> 66: VERSION_BUILD := 0 >>> 67: endif >> >> I think the proposed "solution" is *much* worse than this. > > Reverted to use the

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

2022-11-14 Thread Kim Barrett
On Mon, 14 Nov 2022 16:12:48 GMT, Julian Waters wrote: >> After [JDK-8292008](https://bugs.openjdk.org/browse/JDK-8292008) and >> [JDK-8247283](https://bugs.openjdk.org/browse/JDK-8247283), some C and C++ >> code across the JDK can be replaced and simplified with cleaner language >> features

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

2022-11-14 Thread Julian Waters
On Mon, 14 Nov 2022 13:08:56 GMT, Kim Barrett wrote: >> Julian Waters has updated the pull request incrementally with one additional >> commit since the last revision: >> >> Revert to using simpler solution similar to the original 8274980 > > make/hotspot/lib/CompileJvm.gmk line 67: > >>

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

2022-11-14 Thread Julian Waters
> After [JDK-8292008](https://bugs.openjdk.org/browse/JDK-8292008) and > [JDK-8247283](https://bugs.openjdk.org/browse/JDK-8247283), some C and C++ > code across the JDK can be replaced and simplified with cleaner language > features that were previously not available due to required