Permit the usage of std::invoke in Hotspot

[johan-sjolen]

Hi all,

std::invoke is a C++ feature which provides uniform call syntax for methods, functions, lambdas, and field accesses. This is useful when accessing data from an object whose type is provided by a template and whose accessor is provided separately.

I propose that we permit this in Hotspot, as it's useful when writing generic data structures. This PR adds the required cppstdlib/functional.hpp as well as moving std::invoke from undecided to accepted in the style docs.

Cost

std::invoke has no runtime cost when optimizations are enabled. It does have an increased compilation CPU and memory usage as compared to plain calls.

Reading

https://devblogs.microsoft.com/oldnewthing/20220401-00/?p=106426
https://eggs-cpp.github.io/invoke/benchmark.html

Motivating and pedagogical example

Let's say that we have Persons:

struct Person {
  string name;
  string phone_no;
};

We want O(1) access when looking these up, so we decide to store Persons in a hashtable. However, we don't want to copy the string name key unnecessarily, instead we would like Person to act as the key-value container. So, we set out to implement a generic hashtable that will serve our needs, and we whip this up:

template<typename KV, auto Key>
struct Hashtable {
    // Pretend this is filled with the regular Hashtable stuff :-)
    void get(KV& kv) {
        decltype(auto) key_value = Key(kv);
        // and the rest of the code
    }
};

using PersonTable = Hashtable<Person, &Person::name>
PersonTable my_table;
Person& get_person(string& name) {
   return my_table.get(name);
}

Unfortunately, this will fail to compile. Our accessor is a reference to a field, not a callable method. In swoops std::invoke, allowing us to fix it:

template<typename KV, auto Key>
struct Hashtable {
    // Pretend this is filled with the regular Hashtable stuff :-)
    void get(KV& kv) {
        decltype(auto) key_value = std::invoke(Key, kv);
        // and the rest of the code
    }
};

The nifty thing is that we have a second user that wants to use a public accessor for its key, then std::invoke will work for that case as well:

class Foo {
  int _x;
public:
  int& get_x() { return _x; }
};
using FooTable = Hashtable<Foo, &Foo::get_x>;

Here's a full Godbolt to play around with: https://godbolt.org/z/51eex7T8c

---

• I confirm that I make this contribution in accordance with the OpenJDK Interim AI Policy.

---

Progress

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

Reviewing

Using git

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

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

Using Skara CLI tools

Checkout this PR locally:
$ git pr checkout 31153

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

Using diff file

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

[bridgekeeper]

👋 Welcome back jsjolen! 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]

❗ This change is not yet ready to be integrated.
See the Progress checklist in the description for automated requirements.

[openjdk]

@johan-sjolen 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.

[openjdk]

The total number of required reviews for this PR has been set to 2 based on the presence of this label: hotspot. This can be overridden with the /reviewers command.

[TheShermanTanker]

Ugh, the forbidden method mechanism seems troublesome every time we want to interact with Standard Library headers. Not really a review, just a reminder to myself to continue work on what I'm doing that will hopefully be less painful to work with when enforcing HotSpot Code Style.