This is exactly how Windows allocates the stack. The address space is reserved, but only the first page is comitted; the next page after that is called the guard page. Touching the guard page causes an exception, and the first-chance handler for that exception commits the page, sets up a new guard page at the next position, and resumes execution.

Compilers targeting Windows need to generate stack touching prologues for procedures that allocate more than 4K of local variable data, or else they risk code first touching the page beyond the guard page, which will cause a much more unpleasant access violation.

Ah, I vaguely remember encountering that years ago now that you mention it. I assume it doesn't actually ever purge pages that go unused for a while unless the thread exits?

Hm, isn't that "random idea" the conventional way of assigning thread stacks? Just carve out a piece of virtual address space, and put the stack pointer there. OS maps in memory when the application actually touches the pages. This works great for 64 bit systems. (the difference with your idea is that the memory is never unmapped / returned to the system unless the thread dies)

I realise all user space memory is at some point allocated using a virtual memory mapping. I'm not so sure that explicitly reserving pages which aren't committed is the conventional way to allocate stacks for new threads. In any case, if you don't explicitly purge the pages, a thread will end up using a lot more stack space than necessary if it required a large stack early on in its lifetime.

The author did the Google Go implementation for GCC, so yes he did, and you can see why he'd be concerned with running lots and lots of threads.