| JDK 21 |
|---|
| 21 b20Fixed |
|
Relates :
|
|
|
Relates :
|
|
|
Relates :
|
|
|
Relates :
|
|
|
Relates :
|
Only allocation functions (e.g. `operator new`) that can actually return null should have nothrow exception specs. Having unnecessary nothrow exception specs causes the compiler to generate useless null checks. JDK-8021954 added `throw()` exception specifications to all allocation functions provided by HotSpot. This was in response to a metaspace allocation failure returning null, leading to a crash. The standard (C++03 5.3.4/13, C++14 5.3.4/15) provides the rationale for that change. An allocation function can report allocation failure either by returning null (when it must have a nothrow exception specification), or by throwing `std::bad_alloc` (so obviously must not be declared as non-throwing). The purpose of the nothrow exception spec is to allow a `new` expression to detect a potential null allocation, for which it must itself return null, without attempting initialization. However, the JDK-8021954 change was an over-response to the problem. We only need nothrow exception spes for allocation functions that return null to indicate failure. Many (nearly all?) of our `operator new` functions indicate allocation failure by terminating the program rather than returning null. This is typically determined by a given `operator new` passing the appropriate AllocFailStrategy to the underlying implementation. `Metaspace::allocate` returns null to indicate allocation failure, and many of the callers (including the allocation functions for MetaspaceObj and Klass) just pass that null result along to their callers for appropriate handling. We're also unnecessarily using the gcc option `-fcheck-new`. That option is redundant when the allocation function has a nothrow spec (indicating it can return null), because the compiler will generate the null check regardless of that option. And if the allocation function never returns null (indicated by not having a nothrow spec), then that option is just making the compiler generate a useless null check. StackObj::operator new will need additional adjustment. Perhaps it can just have the allocation and deallocation functions declared deleted?
|