The call stack in basically every programming environment is a virtual memory system with overcommit and allocation that never returns errors.
Conversation
Replying to
Only if you misuse it as such by performing the cursed operation known as recursion.
2
1
Linux kernel will also lazily map in the main thread stack even with overcommit disabled. Runtime has to do something about that during initialization if it wants to guarantee that a certain amount can be used later. An error can occur simply when you reach deepest stack usage.
2
1
That's only for growth beyond the initially committed size, which is a hard coded 128k.
1
It's usually configured to allow 8M though (default since 1995) so programs have grown to rely on being able to put 16k-64k buffers and tons of other data on the stack. It's treated as best practice for performance and it does make a lot of sense. Can avoid the dynamic errors.
Deciding to reserve 1M at process launch isn't much different than reserving 128k. It's an arbitrary number. It's rarely thought about even when programs handle other dynamic allocation failures.
ART just does it because they want a reliable exception on infinite recursion, etc.