[monocasa]

Another ~8MB(8MB plus guard pages) chunk of virtual memory that's free up there near the shared mappings.

You're totally right though, that threads complicated the traditional "stack grows down heap grows up" view of a Unix user address space.

[Myrmornis]

Thanks. So can I check I'm understanding correctly

- If a process has many threads, their stacks are all located within a single virtual address space corresponding to the user process?

- If one thread grows down and is about to overwrite the top of another thread's stack, does the OS detect this automatically and do some sort of reallocation procedure?

[monocasa]

> If a process has many threads, their stacks are all located within a single virtual address space corresponding to the user process?

Yep!

> If one thread grows down and is about to overwrite the top of another thread's stack, does the OS detect this automatically and do some sort of reallocation procedure?

The kernel reserves a 8MB region for each stack and that's it (even the initial stack). So you wouldn't get overlapping stacks per se; the regions are preallocated. The kernel does try to detect stack overflow/underflow with guard pages, but that's just a best attempt kind of thing, and of you underflow by more than page you can just end up just corrupting memory.

And all of this is for C's sort of standard model. 'Split stacks' is a scheme closer to your second question, but there's a lot of overhead of that model, and not a lot of runtimes use it.

I've also even more rarely seen a model that allocates stack frames on the heap and links them together in a linked list.

But like I said, these schemes are very in practice.

[Myrmornis]

Thanks for this.