RFR: 8263476: NMT: Stack guard pages should not be marked as committed

[Albert Mingkun Yang]

On Mon, 4 Aug 2025 04:58:13 GMT, David Holmes <dholmes at openjdk.org> wrote:

> I'm unclear what is actually meant by "commit" in the context of ...

It has the same meaning as "commit" in `os::commit_memory` APIs -- OS promises to offer such memory when accessed, i.e. memory has read/write permission and is accounted in `Committed_AS` on Linux, for example.

> your proposal actually reverses the change that named it this way (JDK-8159335):

That PR used the more precise wording at that time, because we DO commit memory for stack-guard-pages. This PR, however, implements reserve-only memory for stack-guard-pages. In order to avoid confusion, I lifted up the abstraction (back to its original name), because one platform still requires stack-guard-pages to be committed.

The stack-guard-page logic is just invoking `os::guard_memory` on the stack-guard-pages, but among all platforms defined in `src/hotspot/os`, there are 2 platforms that require special treatment, i.e. some preparation work before calling `guard_memory`.

## Linux

In `os::create_attached_thread`, we can see the stack is mapped on demand for primordial thread (main-thread). Therefore, we need to ensure the stack-guard-pages are actually reserved. Handled in the `pd_create_stack_guard_pages` of the current PR. Other threads (non-main-threads) pre-reserve the whole stack, so they don't need special treatment.

## Windows

`guard_memory` requires to-be-guarded memory to be committed.

>From https://learn.microsoft.com/en-us/windows/win32/api/memoryapi/nf-memoryapi-virtualprotect:

"You can set the access protection value on committed pages only."

Therefore, the preparation work for this platform is to commit stack-guard-pages.

-------------

PR Comment: https://git.openjdk.org/jdk/pull/26571#issuecomment-3149830241