8385586: Fix race in Windows map_or_reserve_memory_aligned using VirtualAlloc2 and MapViewOfFile3

[roberttoyonaga]

Summary

Previously on Windows, aligned virtual memory could not be reserved or mapped in a single step. Hotspot used the following race-y pattern on Windows to reserved aligned memory:

• Reserve a large region in order to get an available address range.
• Find the first aligned address within the returned range
• Release the whole region.
• Quickly re-reserve/map a subregion within the original region at the aligned address found earlier.

VirtualAlloc2 and MapViewOfFile3 (available since Windows version 1803) removes the need for this race-y code by supporting alignment natively. I have replaced the race-y part of map_or_reserve_memory_aligned with calls to these new APIs. I have also broken up map_or_reserve_memory_aligned into two separate functions, one path for mapping and one for reserving. It's awkward to have both code paths sandwiched into the same function.

The Windows API functions are dynamically loaded at startup at the end of os::init_2 in os_windows.cpp. This is when os::win32::VirtualAlloc2 and os::win32::MapViewOfFile3 are prepared. If the loading fails, the Windows implementation falls back to the old racey approach.

lookup_kernelbase_library and lookup_kernelbase_symbol have been moved from zSyscall_windows.cpp to os::win32:: to reduce code duplication.

This is a scoped-down version of JDK-8376561 and PR for the sake of easier review. This is the first change in a series of changes that take advantage of VirtualAlloc2 to replace races in Windows code.

---

• 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)

Issue

• JDK-8385586: Fix race in Windows map_or_reserve_memory_aligned using VirtualAlloc2 and MapViewOfFile3 (Enhancement - P4)

Reviewers

• Thomas Stuefe (@tstuefe - Reviewer)

Reviewing

Using git

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

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

Using Skara CLI tools

Checkout this PR locally:
$ git pr checkout 31311

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

Using diff file

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

Using Webrev

Link to Webrev Comment

[bridgekeeper]

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

@roberttoyonaga The following label will be automatically applied to this pull request:

• hotspot

When this pull request is ready to be reviewed, an "RFR" email will be sent to the corresponding mailing list. 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.

[mlbridge]

Webrevs

• 00: Full (e98b6ff8)

[tstuefe]

Any substantial changes over the old PR or just a clean subset?

[roberttoyonaga]

Any substantial changes over the old PR or just a clean subset?

The changes here are just a clean subset of the old bigger PR. I've just dropped everything not related to map_or_reserve_memory_aligned.

[tstuefe]

still looking good

[johan-sjolen]

This is wrong! The previous logging in ZGC did GCPrecious logging and so it needs to be put back where it was. This trace message can be removed, the os::dll_load for Windows already logs log_info(os)("shared library load of %s failed, error code %lu", name, errcode);