Map M:N thread stack chunks initially as PROT_NONE#16232
Merged
jhawthorn merged 1 commit intoruby:masterfrom Mar 5, 2026
Merged
Map M:N thread stack chunks initially as PROT_NONE#16232jhawthorn merged 1 commit intoruby:masterfrom
jhawthorn merged 1 commit intoruby:masterfrom
Conversation
Previously we initially mapped the full 512MB chunk as
PROT_READ|PROD_WRITE and then set a guard page to PROT_NONE the first
time a new thread stack is needed. Usually that's okay as we don't touch
that memory until it is needed and so it doesn't count towards RSS.
However, on Linux even with vm.overcommit_memory=0 (the default) if on a
system (like a tiny cloud VM) with <512MB of RAM+swap that would error
with.
Thread#initialize': can't create Thread: Cannot allocate memory (ThreadError)
This changes the chunk to be mapped initially with PROT_NONE, then
instead of mapping the guard pages we map in the machine and VM stacks
using mprotect. This ensures we don't commit stack memory until it is
first used, and as a side benefit any stray pointers into unused stack
should segfault.
When a stack is freed/reused there is no change from the previous
behaviour, we just use madvise and leave the same regions in place.
[Bug #21944]
c17ce50 to
fe32432
Compare
Member
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
2 participants
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
Previously we initially mapped the full 512MB chunk as PROT_READ|PROD_WRITE and then set a guard page to PROT_NONE the first time a new thread stack is needed. Usually that's okay as we don't touch that memory until it is needed and so it doesn't count towards RSS.
However, on Linux even with
vm.overcommit_memory=0(the default) if on a system (like a tiny cloud VM) with <512MB of RAM+swap that would error with.This changes the chunk to be mapped initially with PROT_NONE, then instead of mapping the guard pages we map in the machine and VM stacks using mprotect. This ensures we don't commit stack memory until it is first used, and as a side benefit any stray pointers into unused stack should segfault.
When a stack is freed/reused there is no change from the previous behaviour, we just use madvise and leave the same regions in place.
The memory layouts are mostly the same (afaict VMA sizes are the same) except around the unallocated space, testing with
RUBY_MN_THREADS=1 ./miniruby -e 'th = 4.times.map { Thread.new { sleep 10 } }; system("cat /proc/#$$/maps")'Before
On linux adjacent VMAs with the same permissions are merged, on macos they aren't. I don't know about other platforms. I think it's probably okay if they aren't.