RFR: 8263476: Use reserved memory for stack guard pages [v3]

Wed Aug 6 08:15:03 UTC 2025

On Wed, 6 Aug 2025 02:03:18 GMT, David Holmes <dholmes at openjdk.org> wrote:

> But this is still inaccurate as there are no changes to Windows. And while I can see where you dropped os::commit for Linux, I can't see what causes changes on the other OS. ?? Is this really just a Linux change?

The PR aims to change for all platforms, but due to platform-specific setting, only BSD and Linux are actually changed. (AIX and Windows ones are just renaming.)

After the change, AIX, BSD, and Linux (excluding main-thread) share the same behavior -- stack-guard-pages mprotected without any preparation. Windows is kept as is, because it's unique requirement on memory-protection.

> You say it removes some complexity but I see no evidence of that in the PR. And doing different things on different platforms reduces the overall understandability of the code.

The removed complexity is the stack-guard-pages preparation logic on BSD and Linux non-main-threads. Due to some intrinsic platform-difference, there will always be some inconsistency. However, the proposed code at least encapsulates that inconsistency to platform-specific logic -- `StackOverflow` doesn't require committing stack-guard-pages, and OS-stack-guard-page APIs don't mandate committing memory.

Maybe I am biased, but I find the new code much easier to read. With the old code, I was quite confused when I first read the linux code -- why we are committing the to-be-mprotected memory, isn't being-reserved enough? After going through all other platforms, I realized that this commit-requirement stems from Windows-specific memory-protection-needs-committed-memory. This seems like a leaky abstraction that exposes a platform-specific oddity on the shared API level.

> ... propvide a convincing argument as to why the changes can be determined correct by observation ...

How about the new diagram I added in `os::pd_create_stack_guard_pages` for linux main-thread?

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

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