8369187: Add wrapper for <new> that forbids use of global allocation and deallocation functions

[kimbarrett]

8369187: Add wrapper for that forbids use of global allocation and deallocation functions

Please review this change that adds cppstdlib/new.hpp as a wrapper for
including <new>. All existing inclusions of <new> are changed to include
the new wrapper.

In additional to including <new>, this wrapper also provides deprecation
declarations to prevent the use of some facilities by HotSpot code.

However, those deprecations need to be conditionalized to not apply to gtests,
so this change also adds a macro definition provided by the build system for
use in detecting that a header is being included by a gtest.

Testing: mach5 tier1

---

Progress

• Change must be properly reviewed (1 review required, with at least 1 Reviewer)
• Change must not contain extraneous whitespace
• Commit message must refer to an issue

Issue

• JDK-8369187: Add wrapper for <new> that forbids use of global allocation and deallocation functions (Enhancement - P4)

Reviewers

• Stefan Karlsson (@stefank - Reviewer) 🔄 Re-review required (review applies to 11c088e1)

Reviewing

Using git

Checkout this PR locally:
$ git fetch https://git.openjdk.org/jdk.git pull/28250/head:pull/28250
$ git checkout pull/28250

Update a local copy of the PR:
$ git checkout pull/28250
$ git pull https://git.openjdk.org/jdk.git pull/28250/head

Using Skara CLI tools

Checkout this PR locally:
$ git pr checkout 28250

View PR using the GUI difftool:
$ git pr show -t 28250

Using diff file

Download this PR as a diff file:
https://git.openjdk.org/jdk/pull/28250.diff

Using Webrev

Link to Webrev Comment

[bridgekeeper]

👋 Welcome back kbarrett! A progress list of the required criteria for merging this PR into master will be added to the body of your pull request. There are additional pull request commands available for use with this pull request.

[openjdk]

@kimbarrett This change is no longer ready for integration - check the PR body for details.

[openjdk]

@kimbarrett The following labels will be automatically applied to this pull request:

• build
• hotspot

When this pull request is ready to be reviewed, an "RFR" email will be sent to the corresponding mailing lists. If you would like to change these labels, use the /label pull request command.

[mlbridge]

Webrevs

• 02: Full (2d83b34f)
• 01: Full - Incremental (11c088e1)
• 00: Full (103f7c2b)

[stefank]

At cppreference this is declared as:

inline constexpr size_t hardware_destructive_interference_size

Is that why you're getting the Visual Studio error?

[kimbarrett]

It can't be redeclared with the [[deprecated]] attribute using that form.
constexpr requires an initializer, and what should the value be? And all
inline declarations need to be "exactly the same" (which has a technical
meaning somewhere that talks about equivalent token sequences).

Removing extern, adding inline, or both leads to gcc to (quite correctly,
I think) rejecting it as a redefinition.

I think the form being used here does have the same storage class. I think
both forms declare a variable with namespace scope and external linkage; C++17
6.5. And both gcc and clang accept it. I think it's an MSVC bug of being
overly restrictive, rather than both gcc and clang being overly permissive.

[stefank]

I'm still note convinced that the above does what you intended to do here, but the result seems to be the same so I guess that's fine.

If I compile a small test:

#include <stdio.h>

[[deprecated]] inline constexpr int my_deprecated = 1;

int main() {
  printf("my_deprecated: %d\n", my_deprecated);
  return 0;
}

I get:

$ g++ -std=c++17 -Wall -Wextra -pedantic h.cpp
h.cpp:6:33: warning: 'my_deprecated' is deprecated [-Wdeprecated-declarations]
    6 |   printf("my_deprecated: %d\n", my_deprecated);
      |                                 ^
h.cpp:3:3: note: 'my_deprecated' has been explicitly marked deprecated here
    3 | [[deprecated]] inline constexpr int my_deprecated = 1;
      |   ^
1 warning generated.

But if I try to compile something similar to the above code I don't get the deprecated warning:

#include <stdio.h>
#include <new>

namespace std {
[[deprecated]] extern const size_t hardware_destructive_interference_size;
};

int main() {
  printf("x = %zu\n", std::hardware_destructive_interference_size);
  return 0;
}

Now I get:

$ g++ -std=c++17 -Wall -Wextra -pedantic g.cpp
g.cpp:9:28: error: reference to 'hardware_destructive_interference_size' is ambiguous
    9 |   printf("x = %zu\n", std::hardware_destructive_interference_size);
      |                       ~~~~~^
/Library/Developer/CommandLineTools/SDKs/MacOSX.sdk/usr/include/c++/v1/__new/interference_size.h:25:25: note: candidate found by name lookup is 'std::__1::hardware_destructive_interference_size'
   25 | inline constexpr size_t hardware_destructive_interference_size  = __GCC_DESTRUCTIVE_SIZE;
      |                         ^
g.cpp:5:36: note: candidate found by name lookup is 'std::hardware_destructive_interference_size'
    5 | [[deprecated]] extern const size_t hardware_destructive_interference_size;
      |                                    ^
1 error generated.

where the end result is that we get a warning about an ambiguous lookup and not a warning that this has been deprecated.

[kimbarrett]

Getting the desired behavor seems to require a sufficiently recent compiler.
Changed to only redeclare these variables deprecated accordingly. It's kind of
messy. We could just skip these deprecations, though having put in the work to
find good versions...

[kimbarrett]

I added to globalDefinitions.hpp deprecating declarations for some of the
implicitly declared allocation and deallocation functions. This provides
better coverage for the usage poisoning.