JDK-8306579 : Consider building with /Zc:throwingNew
  • Type: Enhancement
  • Component: infrastructure
  • Sub-Component: other
  • Affected Version: 21
  • Priority: P4
  • Status: Resolved
  • Resolution: Fixed
  • OS: windows
  • Submitted: 2023-04-20
  • Updated: 2025-03-04
  • Resolved: 2025-01-13
The Version table provides details related to the release that this issue/RFE will be addressed.

Unresolved : Release in which this issue/RFE will be addressed.
Resolved: Release in which this issue/RFE has been resolved.
Fixed : Release in which this issue/RFE has been fixed. The release containing this fix may be available for download as an Early Access Release or a General Availability Release.

To download the current JDK release, click here.
JDK 25
25 b06Fixed
Related Reports
Relates :  
JDK-8342639 - Global operator new in adlc has wrong exception spec
Relates :  
JDK-8349100 - Regression >3% with J2dBench-vimg_text_aa across all of 24
Relates :  
JDK-8305590 - Remove nothrow exception specifications from operator new
Description
JDK-8305590 removes `-fcheck-new` when building with gcc. It turns out Visual Studio has a similar option, though inverted in behavior and default.

It seems like /Zc:throwingNew- (the default) corresponds to gcc -fcheck-new, and /Zc:throwingNew corresponds to -fno-check-new (the default).

The Visual Studio documentation strongly recommends using /Zc:throwingNew if possible, as turning it off (the default) seriously bloats code and inhibits optimizations.
https://learn.microsoft.com/en-us/cpp/build/reference/zc-throwingnew-assume-operator-new-throws?view=msvc-170

As mentioned in JDK-8305590, the standard says that 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).  HotSpot allocation functions terminate the program instead of throwing on allocation failure, so similarly don't need the result checked for null.

The documentation for /Zc:throwingNew is somewhat vague and confusing, so some investigation is probably needed to verify it really has the desired effect for us.
Comments
Changeset: a289bcfe Branch: master Author: Julian Waters <jwaters@openjdk.org> Date: 2025-01-13 14:02:41 +0000 URL: https://git.openjdk.org/jdk/commit/a289bcfe7e2786d05c338712b818fc4ef12cb4ac
13-01-2025
A pull request was submitted for review. Branch: master URL: https://git.openjdk.org/jdk/pull/22039 Date: 2024-11-12 14:30:05 +0000
12-11-2024
I'm glad I joined JDK development long after Visual Studio 6.0 support was gone. I can't imagine what nightmares people have while having to maintain code for such an old Visual Studio version back then :P
20-10-2024
[~jwaters] In src/java.desktop/windows/native/libawt/windows there are a number of files containing declarations or definitions of operator new. None of them have exception specifications. So far as I can tell, all of them will report failure by throwing std::bad_alloc. One of them, in awt_new.cpp, looks like it should just be nuked. https://github.com/openjdk/jdk/blob/309b929147e7dddfa27879ff31b1eaad271def85/src/java.desktop/windows/native/libawt/windows/awt_new.cpp#L117-L126 https://learn.microsoft.com/en-us/cpp/build/reference/zc-throwingnew-assume-operator-new-throws?view=msvc-170 "Versions of Visual C++ up to Visual Studio 6.0 returned a null pointer on an allocation failure. " We're not supporting Visual Studio 6.0 anymore. :)
19-10-2024
Just a heads up, before this can be done, some fixing has to be done in awt on the Windows end, as Daniel says. In particular, there is a definition of global new that overrides the default in the awt allocator somewhere (Can't remember which file off the top of my head)
19-10-2024
Thanks for the clarification. The information about the effect of exception specifications was missing on https://en.cppreference.com/w/cpp/memory/new/operator_new, which is my usual source of c++ answers. I can confirm that your description of the contents of c++14 standard is accurate. Given that the next RDP is still far away, would it be a good time to make this change?
13-09-2023
It's not true that only the default operator new (which HotSpot doesn't use) is guaranteed to never return null. HotSpot provides lots of class-scoped allocation functions (e.g. operator new). The standard (C++03 5.3.4/13, C++14 5.3.4/15) specifies different behavior for `new` expressions depending on whether the invoked allocation function has a nothrow exception specification or not. If it does, then the `new` expression must check for a null result from the allocation function and return null without calling the constructor. If the allocation function isn't noexcept, then the `new` expression doesn't need to check for a null result and can unconditionally call the constructor on the memory returned by the allocation function. JDK-8305590 cleaned up our allocation function exception specifications. Those that can return null now have a nothrow exception specification. Those that don't return null (for HotSpot, terminating the program rather than throwing an exception) don't have a nothrow exception specification. But the default /Zc:throwingNew- doesn't take advantage of that. Instead, `new` expressions unconditionally check for a null result from the allocation function, irrespective of the exception specification (or lack thereof). JDK-8305590 removed -fcheck-new, improving generated code for gcc and clang based platforms. This issue proposes making the similar change for Visual Studio based platforms.
13-09-2023
If I understand the docs correctly, enabling Zc:throwingNew would have no effect on Hotspot. The CPP language [1] defines a number of overloads; only the default operator new is guaranteed to never return null. Using the non-allocating placement new on a null pointer is UB, and the user-defined and class-specific variants are permitted to return null. With that in mind, Zc:throwingNew could only change the behavior of the default operator, and that operator is forbidden in hotspot. The flag might still be beneficial for java.desktop; the default operator appears to be used heavily in that area. [1] https://en.cppreference.com/w/cpp/memory/new/operator_new
13-09-2023