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

[David Holmes]

On Mon, 4 Aug 2025 14:04:15 GMT, Albert Mingkun Yang <ayang at openjdk.org> wrote:

>> Use reserved (instead of committed) memory for stack-guard-pages on linux like systems.
>> 
>> `os::must_commit_stack_guard_pages` uses `commit` in its name, but `commit` usually has specific meanings in OS memory context. The actual question the caller is asking is whether the caller needs to do some preparation work before marking the guard-pages as inaccessible. To avoid confusion, I changed it to "allocate". Other suggestions are welcome.
>> 
>> Test: tier1-3
>
> Albert Mingkun Yang has updated the pull request incrementally with one additional commit since the last revision:
> 
>   review

> Use reserved (instead of committed) memory for stack-guard-pages on linux like systems.

Why? What is the difference? Can we fail to get a stack-page when we need it if it was only reserved?

The issue description seems concerned with NMT output but you are actually making a significant change to the guard-page functionality  and I don't understand the motivation for doing so.

> In os::create_attached_thread, we can see the stack is mapped on demand for primordial thread (main-thread).

Note that this is not an expected case and we don't really support running the VM on the primordial thread and strongly advise against it. How did you test this?

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

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