Disadvantages of increasing Stack Size and difference between Stack Commit and Reserve

Question

I recently encountered a Stack Overflow issue with the Dinkumware C++11 <regex> library, and so far I've got around it by doubling Stack Commit and Stack Reserve sizes (I've not encountered any issues yet).

However, I'm curious as to whether there are any disadvantages to increasing the stack size, and moreover, I'm not entirely sure what the difference between the Stack Commit and Stack Reserve is (however the stack commit is considerably smaller than the stack reserve).

Answer 1

The OBVIOUS consequence of increasing the stack-size is more memory usage. Since the stack isn't enormous in comparison to overall memory in most cases, it's not a big issue.

Obviously, if there are many threads using large stacks each, then that can amount to a large amount of the available memory in the machine - particularly if the machine hasn't got huge amounts of memory in the first place.

"Reserved" space is allocated but not actually physically present until it has been "touched" - in other words, the physical memory space is not allocated for the stack here - just some space taken out of the virtual memory map for the allocation (so, if you are tight on virtual space because your application needs as much memory as it can get in a 32-bit environment, then it may still be a factor).

"Committed" space has physical memory attached to it (it can still be swapped out to disk, but somewhere, the physical memory must be available). This is much more a factor in a system that is short of overall memory, which tends to be less common these days, with machines having multiple gigabytes of RAM available.

A side-effect of using large reserved region that isn't committed is that the application may cause the system to run out of physical memory, which can't be detected by the application, since the "error" happens simply by accessing memory, but there isn't any physical memory available (including swap-space), so the application will have to be killed [or some other application that "looks guilty" in the case of Linux OOM killer].