RFR: 8302124: HotSpot Style Guide should permit noreturn attribute

[Thomas Stuefe]

On Fri, 10 Feb 2023 05:26:38 GMT, Kim Barrett <kbarrett at openjdk.org> 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