diff --git a/doc/hotspot-style.html b/doc/hotspot-style.html
index 22fd7b8167b..dafd29d6f54 100644
--- a/doc/hotspot-style.html
+++ b/doc/hotspot-style.html
@@ -87,6 +87,7 @@ id="toc-local-function-objects">Local Function Objects
Inheriting constructors
Attributes
+noexcept
Additional Permitted
Features
@@ -1140,6 +1141,58 @@ function name and the parameter list.
memory_order_consume.
[[deprecated]] - Not relevant in HotSpot code.
+noexcept
+Use of noexcept exception specifications (n3050) are permitted with restrictions
+described below.
+
+- Only the argument-less form of
noexcept exception
+specifications are permitted.
+- Allocation functions that may return
nullptr to
+indicate allocation failure must be declared noexcept.
+- All other uses of
noexcept exception specifications are
+forbidden.
+noexcept expressions are forbidden.
+- Dynamic exception specifications are forbidden.
+
+HotSpot is built with exceptions disabled, e.g. compile with
+-fno-exceptions (gcc, clang) or no /EH option
+(MSVC++). So why do we need to consider noexcept at all?
+It's because noexcept exception specifications serve two
+distinct purposes.
+The first is to allow the compiler to avoid generating code or data
+in support of exceptions being thrown by a function. But this is
+unnecessary, because exceptions are disabled.
+The second is to allow the compiler and library code to choose
+different algorithms, depending on whether some function may throw
+exceptions. This is only relevant to a certain set of functions.
+
+Some allocation functions (operator new and
+operator new[]) return nullptr to indicate
+allocation failure. If a new expression calls such an
+allocation function, it must check for and handle that possibility.
+Declaring such a function noexcept informs the compiler
+that nullptr is a possible result. If an allocation
+function is not declared noexcept then the compiler may
+elide that checking and handling for a new expression
+calling that function.
+Certain Standard Library facilities (notably containers) provide
+different guarantees for some operations (and may choose different
+algorithms to implement those operations), depending on whether certain
+functions (constructors, copy/move operations, swap) are nothrow or not.
+They detect this using type traits that test whether a function is
+declared noexcept. This can have a significant performance
+impact if, for example, copying is chosen over a potentially throwing
+move. But this isn't relevant, since HotSpot forbids the use of most
+Standard Library facilities.
+
+HotSpot code can assume no exceptions will ever be thrown, even from
+functions not declared noexcept. So HotSpot code doesn't
+ever need to check, either with conditional exception specifications or
+with noexcept expressions.
+Dynamic exception specifications were deprecated in C++11. C++17
+removed all but throw(), with that remaining a deprecated
+equivalent to noexcept.
Additional Permitted
Features
diff --git a/doc/hotspot-style.md b/doc/hotspot-style.md
index 92b756e10d3..0a0089ee454 100644
--- a/doc/hotspot-style.md
+++ b/doc/hotspot-style.md
@@ -1130,6 +1130,57 @@ The following attributes are expressly forbidden:
* `[[carries_dependency]]` - Related to `memory_order_consume`.
* `[[deprecated]]` - Not relevant in HotSpot code.
+### noexcept
+
+Use of `noexcept` exception specifications
+([n3050](http://wg21.link/n3050))
+are permitted with restrictions described below.
+
+* Only the argument-less form of `noexcept` exception specifications are
+permitted.
+* Allocation functions that may return `nullptr` to indicate allocation
+failure must be declared `noexcept`.
+* All other uses of `noexcept` exception specifications are forbidden.
+* `noexcept` expressions are forbidden.
+* Dynamic exception specifications are forbidden.
+
+HotSpot is built with exceptions disabled, e.g. compile with `-fno-exceptions`
+(gcc, clang) or no `/EH` option (MSVC++). So why do we need to consider
+`noexcept` at all? It's because `noexcept` exception specifications serve two
+distinct purposes.
+
+The first is to allow the compiler to avoid generating code or data in support
+of exceptions being thrown by a function. But this is unnecessary, because
+exceptions are disabled.
+
+The second is to allow the compiler and library code to choose different
+algorithms, depending on whether some function may throw exceptions. This is
+only relevant to a certain set of functions.
+
+* Some allocation functions (`operator new` and `operator new[]`) return
+`nullptr` to indicate allocation failure. If a `new` expression calls such an
+allocation function, it must check for and handle that possibility. Declaring
+such a function `noexcept` informs the compiler that `nullptr` is a possible
+result. If an allocation function is not declared `noexcept` then the compiler
+may elide that checking and handling for a `new` expression calling that
+function.
+
+* Certain Standard Library facilities (notably containers) provide different
+guarantees for some operations (and may choose different algorithms to
+implement those operations), depending on whether certain functions
+(constructors, copy/move operations, swap) are nothrow or not. They detect
+this using type traits that test whether a function is declared `noexcept`.
+This can have a significant performance impact if, for example, copying is
+chosen over a potentially throwing move. But this isn't relevant, since
+HotSpot forbids the use of most Standard Library facilities.
+
+HotSpot code can assume no exceptions will ever be thrown, even from functions
+not declared `noexcept`. So HotSpot code doesn't ever need to check, either
+with conditional exception specifications or with `noexcept` expressions.
+
+Dynamic exception specifications were deprecated in C++11. C++17 removed all
+but `throw()`, with that remaining a deprecated equivalent to `noexcept`.
+
### Additional Permitted Features
* `alignof`