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

Thomas Stuefe stuefe at openjdk.org
Fri Aug 8 15:23:26 UTC 2025


On Wed, 6 Aug 2025 11:40:38 GMT, Albert Mingkun Yang <ayang at openjdk.org> wrote:

> > Apart from being hard to understand, it also opens a time window where the stack guard pages are unmapped;
> 
> Could you elaborate which part is hard to understand? I think the newly added diagram illustrates the stack-frame clearly.

Why we first unmap the stack area to then re-map it again, leading to the potential race I mentioned.

> 
> > but in this time window someone else may have mapped pages in there.
> 
> Since Linux main-thread dynamically reserves memory for stack, it's always possible that address-ranges smaller than stack-top (including stack-guard-pages) are already reserved by others.

Sorry, you lost me. What is stack_top in your description? Lowest or highest address? 

Are you saying that parts of the stack, including what is supposed to carry the stack guard, can be reserved by others? That cannot be true, otherwise we would destroy their mappings. Since we do an unconditional munmap, I assume the underlying pages are guaranteed to belong to this stack.

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

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


More information about the hotspot-runtime-dev mailing list