Why is stack memory size so limited?

by

My intuition is the following. The stack is not as easy to manage as the heap. The stack need to be stored in continuous memory locations. This means that you cannot randomly allocate the stack as needed, but you need to at least reserve virtual addresses for that purpose. The larger the size of the reserved virtual address space, the fewer threads you can create.

For example, a 32-bit application generally has a virtual address space of 2GB. This means that if the stack size is 2MB (as default in pthreads), then you can create a maximum of 1024 threads. This can be small for applications such as web servers. Increasing the stack size to, say, 100MB (i.e., you reserve 100MB, but do not necessarily allocated 100MB to the stack immediately), would limit the number of threads to about 20, which can be limiting even for simple GUI applications.

A interesting question is, why do we still have this limit on 64-bit platforms. I do not know the answer, but I assume that people are already used to some “stack best practices”: be careful to allocate huge objects on the heap and, if needed, manually increase the stack size. Therefore, nobody found it useful to add “huge” stack support on 64-bit platforms.

More Related Contents:

  1. Why should C++ programmers minimize use of ‘new’?
  2. What uses are there for “placement new”?
  3. How do malloc() and free() work?
  4. What is the difference between new/delete and malloc/free?
  5. Is delete[] equal to delete?
  6. C++ new int[0] — will it allocate memory?
  7. Dynamically allocating an array of objects
  8. How could pairing new[] with delete possibly lead to memory leak only?
  9. Compelling examples of custom C++ allocators?
  10. How to get available memory C++/g++?
  11. C++, Free-Store vs Heap
  12. How does a C++ reference look, memory-wise?
  13. Any reason to overload global new and delete?
  14. Are memory leaks “undefined behavior” class problem in C++?
  15. How to know if a pointer points to the heap or the stack?
  16. Does delete on a pointer to a subclass call the base class destructor?
  17. Check if a pointer points to allocated memory on the heap
  18. What is the behavior of “delete” with stack objects? [duplicate]
  19. Reason why not to have a DELETE macro for C++
  20. Why, really, deleting an incomplete type is undefined behaviour?
  21. What is “bit padding” or “padding bits” exactly?
  22. Does this type of memory get allocated on the heap or the stack?
  23. How do I call the original “operator new” if I have overloaded it?
  24. How to alloc a executable memory buffer?
  25. When do programmers use Empty Base Optimization (EBO)
  26. vector memory allocation strategy
  27. If a 32-bit integer overflows, can we use a 40-bit structure instead of a 64-bit long one?
  28. “Right” way to deallocate an std::vector object
  29. What happen to pointers when vectors need more memory and realocate memory?
  30. C++ delete does not free all memory (Windows)

Leave a Comment