> Sure, but this can be configured :) Someone in one forum said they were able to set their system's stack size to "unlimited" and were able to utilize more tha

> Sure, but this can be configured :) Someone in one forum said they were able to set their system's stack size to "unlimited" and were able to utilize more than 500MB of stack space in a quick test Yeah, but run the same test in a multithreaded program and it is no longer that easy. > This is the closest I've heard to a real explanation so far. Still- if the downside is just performance, would the cache benefits not potentially outweigh the performance downsides? I'm not a compiler engineer, but if I were I would definitely do some experiments around this. Maybe people already have and it's known to be a dead end? The performance downsides is that every allocation on the stack could cause an overflow and therefore needs to be checked. Every CALL instruction and everytime you declare a local variable. Maybe with smart compiler optimizations you could get rid of some of these checks, but I don't think you could get rid of them entirely. The other big problem that I didn't mention in my last comment is that the language needs to support movable pointers. If you move a stack to a new memory segment all pointers to locations in the stack suddenly becomes invalid and has to be updated. For small and fixed allocations, allocating on the stack when possible is certainly a good performance boost over heap allocations, but the advantage may not be very big for large dynamic allocations.