2

As far as I know the Linux stack size limit is 8 MB, but on 64-bit machines there's no reason why it couldn't be massively increased, e.g. to 4 GB. This would allow programmers to mostly not worry about storing large values on the stack, or using recursive algorithms instead of iterative.

It should also be faster because stack allocation is much much faster than heap allocation. We could see a whole new class of stack allocated data structures - imagine std::stack_vector<T> which allocates on the stack.

Is there a downside I'm not seeing? Or is it just that nobody has cared enough to make the change?

Improve this question
15
  • I am just running a browser and a terminal, and I have close on 200 processes. You want to reserve 800 GB before I run any applications? Also, data on stack is transient -- it lasts only while the function that declared the data object is in scope. It can be done (ALGOL had no heap) but it was very constraining. On the other hand, my first mainframe had no stack. Commented Oct 12, 2021 at 8:56
  • "You want to reserve 800 GB before I run any applications?" Yes - 800GB of virtual memory. There's no issue with that on 64-bit machines. Commented Oct 12, 2021 at 9:43
  • @ilkkachu: std::vector<> always stores its data on the heap. Only a pointer to the data and the size/capacity counters are stored on the stack. Commented Oct 12, 2021 at 9:44
  • 3
    Some consider 8MiB to be huge ;-) Commented Oct 12, 2021 at 10:25
  • 1
    "using recursive algorithms instead of iterative" it only makes sense to use "recursive algorithms" with a language with mandatory tail-call elimination, like scheme. "Yes - 800GB of virtual memory. There's no issue with that on 64-bit machines" by that you're forcing the kernel to horribly overcommit, and when actual memory gets tight, the kernel won't be able to determine which commitments it should fullfill and which it should drop; the program which really needs to work with a large dataset at once, or the program whose author couldn't be bothered to learn how to program ;-) Commented Oct 12, 2021 at 18:09

1 Answer 1

Reset to default
2

While limiting stack size might originaly have been done to save virtual memory, another benefit is that it catches infinite recursions. Algorithms that require really deep recursion are not common, so if you're using an enormous amount of stack it's more likely to be a bug. This doesn't become less likely when switching to a 64-bit architecture.

An algorithm is likely to use more stack space in 64-bit mode because some data types are larger, but probably not so much that the stack size limit becomes a problem.

It's true that this limit also prevents allocating large arrays on the stack, which could be more efficient. But is fixing this important enough to lose the above infinite recursion check?

Improve this answer
4
  • 1
    Hmmm detecting accidental recursion seems like a reasonable advantage at least, thanks! Commented Oct 13, 2021 at 12:53
  • Edge-case I ran into: When working with Intel Fortran, automatic arrays (i.e. arrays declared with the size parameter being a runtime variable) and temporary arrays (e.g. the result of the expression matmul(A, B)) are stored on the stack, which a colleague benchmarked to have relevant impact on overall performance. Sadly, the implementation does this for arrays of any size, such that we ran into situations where matmul(A,B) was crashing the software under the default 16 MB stack size limit. Point being: Small default, combined with corporate ITs making it hard to change, can be an issue. Commented May 18, 2023 at 6:55
  • 2
    Infinite recursion would always be eventually detected regardless of stack size, it's not like if you set the stack limit beyond a certain amount then you won't be able to detect infinite recursion. Commented Feb 3, 2024 at 15:33
  • If you don't have a hard limit to stack size, you only detect it by accident due to overwriting the heap or something else and causing some other misbehavior. Commented Feb 4, 2024 at 2:00

You must log in to answer this question.

Start asking to get answers

Find the answer to your question by asking.

Ask question

Explore related questions

See similar questions with these tags.