On Fri, 10 Feb 2023 05:26:38 GMT, Kim Barrett <[email protected]> wrote:
> Please review this change to permit the use of noreturn attributes in HotSpot > code. > > http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2008/n2761.pdf > https://en.cppreference.com/w/cpp/language/attributes/noreturn > > This will permit such changes as marking failed assertions and the like as > noreturn, permitting the compiler to generate better code in some cases. This > has benefits even in product builds, since some of the relevant checks occur > in product code (such as `guarantee`, `fatal`, &etc). It also provides a > solution to the problem described in JDK-8294031, where the potential > continued execution from a failed assertion leads to compiler warnings. > > The change is written in such a way that it should be easy to add the > appropriate text for new attributes in the future. There have been > discussions of adopting C++17, which adds several attributes. > > The change to the Style Guide is forward looking, toward a time when more > attributes are available due to the adoption of a newer language standard than > the current C++14. It is written in such a way that it should be easy to add > the appropriate text for new attributes. > > Testing: > I have a prototype of making HotSpot assertions noreturn, which has been run > through mach5 tier1-8 for all Oracle-supported platforms. > > This is a modification of the Style Guide, so rough consensus among the > HotSpot Group members is required to make this change. Only Group members > should vote for approval (via the github PR), though reasoned objections or > comments from anyone will be considered. A decision on this proposal will not > be made before Friday 24-Feb-2023 at 12h00 UTC. > > Since we're piggybacking on github PRs here, please use the PR review process > to approve (click on Review Changes > Approve), rather than sending a "vote: > yes" email reply that would be normal for a CFV. This sounds useful. I try to think of cases where the fact that the compiler optimizes away follow-up instructions could be surprising. But with noreturn the compiler should warn, right, about non-reachable instructions? ------------- PR: https://git.openjdk.org/jdk/pull/12507
