In adlc/main.cpp there is a global definition of
`operator new(size_t, int, const char*, int) throw()`
https://github.com/openjdk/jdk/blob/309b929147e7dddfa27879ff31b1eaad271def85/src/hotspot/share/adlc/main.cpp#L494-L498
It is conditionally defined, being defined for
`!defined(_WIN32) || _WIN64`
and used to (untilJDK-8288094) additionally be defined if
`_MSC_VER < 14`
with a comment that VS 2005 provides a definition.
(Other than the _MSC_VER check removal, this has been present since before the mercurial age.)
So it is defined for non-Windows and _WIN64, and (previously) for _WIN32 with a sufficiantly old version of VS.
So what is this for? Well, it turns out there is a declaration for it in vcruntime_new_debug.h, so it's part of the VS runtime support. That declaration doesn't have the nothrow exception specification that our definition has. I stumbled across this when trying to build with C++17, where the exception specification mismatch gets rejected. The nothrow exception spec was added by JDK-8021954. It should have been removed byJDK-8305590, but appears to have been overlooked.
We don't use it directly. I didn't try to figure out whether we ever used it directly, but doubt it. I suspect we never did, and it only exists to support building adlc in some configuration where debug declarations from the VS runtime library were used but the corresponding library wasn't linked or didn't provide a definition.
The simplest change that would permit building with C++17 is to remove the nothrow exception specification from our definition.
Additionally, it seems likely that defining it for non-Windows is unnecessary, and we could remove the `!defined(_WIN32)` part of the conditional.
It might even be that we can remove the definition entirely.
Our definition calls the global `operator new(size_t)`, and the default implementation throws, though I'm not sure what it does when building with exceptions disabled. AndJDK-8306579 might also be relevant. These all seem like arguments for removing the definition entirely if we can.
`operator new(size_t, int, const char*, int) throw()`
https://github.com/openjdk/jdk/blob/309b929147e7dddfa27879ff31b1eaad271def85/src/hotspot/share/adlc/main.cpp#L494-L498
It is conditionally defined, being defined for
`!defined(_WIN32) || _WIN64`
and used to (until
`_MSC_VER < 14`
with a comment that VS 2005 provides a definition.
(Other than the _MSC_VER check removal, this has been present since before the mercurial age.)
So it is defined for non-Windows and _WIN64, and (previously) for _WIN32 with a sufficiantly old version of VS.
So what is this for? Well, it turns out there is a declaration for it in vcruntime_new_debug.h, so it's part of the VS runtime support. That declaration doesn't have the nothrow exception specification that our definition has. I stumbled across this when trying to build with C++17, where the exception specification mismatch gets rejected. The nothrow exception spec was added by JDK-8021954. It should have been removed by
We don't use it directly. I didn't try to figure out whether we ever used it directly, but doubt it. I suspect we never did, and it only exists to support building adlc in some configuration where debug declarations from the VS runtime library were used but the corresponding library wasn't linked or didn't provide a definition.
The simplest change that would permit building with C++17 is to remove the nothrow exception specification from our definition.
Additionally, it seems likely that defining it for non-Windows is unnecessary, and we could remove the `!defined(_WIN32)` part of the conditional.
It might even be that we can remove the definition entirely.
Our definition calls the global `operator new(size_t)`, and the default implementation throws, though I'm not sure what it does when building with exceptions disabled. And
- relates to
-
JDK-8305590 Remove nothrow exception specifications from operator new
-
- Resolved
-
-
JDK-8339783 Implement JEP 479: Remove the Windows 32-bit x86 Port
-
- Resolved
-
-
JDK-8288094 cleanup old _MSC_VER handling
-
- Resolved
-
-
JDK-8306579 Consider building with /Zc:throwingNew
-
- Resolved
-