| JDK 26 |
|---|
| 26 b02Fixed |
|
Relates :
|
|
|
Relates :
|
|
|
Relates :
|
|
|
Relates :
|
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 (until JDK-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 by JDK-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. And JDK-8306579 might also be relevant. These all seem like arguments for removing the definition entirely if we can.
|