5 ms·

The amount of stack you pay for on a thread is proportional to the maximum depth that the stack ever reached on the thread. Operating systems can grow the amoun

The amount of stack you pay for on a thread is proportional to the maximum depth that the stack ever reached on the thread. Operating systems can grow the amount of real memory allocated to a thread, but never shrink it. It’s a programming model that has some really risky drawbacks.

matheusmoreira 5mo ago
> Operating systems can grow the amount of real memory allocated to a thread, but never shrink it. Operating systems can shrink the memory usage of a stack. madvise(page, size, MADV_DONTNEED); Leaves the memory mapping intact but the kernel frees underlying resources. Subsequent accesses get either new zero pages or the original file's pages. Linux also supports mremap, which is essentially a kernel version of realloc. Supports growing and shrinking memory mappings. stack = mremap(stack, old_size, old_size / 2, MREMAP_MAYMOVE, 0); Whether existing systems make use of this is another matter entirely. My language uses mremap for growth and shrinkage of stacks. C programs can't do it because pointers to stack allocated objects may exist.
- simonask 5mo ago
  Stack memory is never unmapped until the thread terminates as far as I know. I don’t know of any kernel that does this, for precisely the reason you arrive at by the very last sentence.
  - matheusmoreira 5mo ago
    It's just normal pages to the kernel. In theory, it's totally possible for the program to munmap some of its own stack's pages if it was sophisticated enough. Typical C programs just aren't capable of it, at least not without great effort.
- dwattttt 5mo ago
  > C programs can't do it because pointers to stack allocated objects may exist. They sure shouldn't exist to the unused region of the stack though; if they do, that's a bug (because anything could claim that memory now). You should be free and clear to release stack pages past your current stack pointer.
  - simonask 5mo ago
    There isn’t any operating system or compiler that does this today, and it probably isn’t worth it to pursue. Enlarging the stack via page fault is really expensive, so you would need really advanced heuristics to prevent repeatedly unmapping/remapping those pages. The correct tool for myriad of small tasks is coroutines / green threads / async tasks, so why spend any energy optimizing threads for that purpose instead of what they are already good at?
    - dwattttt 5mo ago
      In the general case it's absolutely not worth it. In the context of "you want a large number of OS threads, and are willing to go to some effort", it's theoretically something you'd want to do; suppose the startup for a thread is measurably a high water mark for stack usage, after startup the steady state stack usage won't exceed 20% of that high mark, and you'd like as many threads/stacks as possible. Coroutines / green threads / async tasks will all do this too, but there's something to be said for using/relying on the system scheduler instead of bringing your own in in addition.
  - matheusmoreira 5mo ago
    High level languages have entire runtime systems dedicated to managing resources like that. My language can allocate, grow, shrink and deallocate stacks dynamically. It has complete visibility into everything, and the stacks themselves are designed to be relocatable and position-independent. In C it's impossible to even get the stack pointer without dropping to assembly or using compiler builtins. It's hard to know where the stack starts or even how big it is.
    - dwattttt 5mo ago
      I do agree with this, but just to be clear (for others), you don't need any runtime managing resource lifecycles to know that there shouldn't be pointers into free memory, such as the currently unused portion of the stack.

matheusmoreira 5mo ago

> Operating systems can grow the amount of real memory allocated to a thread, but never shrink it. Operating systems can shrink the memory usage of a stack. madvise(page, size, MADV_DONTNEED); Leaves the memory mapping intact but the kernel frees underlying resources. Subsequent accesses get either new zero pages or the original file's pages. Linux also supports mremap, which is essentially a kernel version of realloc. Supports growing and shrinking memory mappings. stack = mremap(stack, old_size, old_size / 2, MREMAP_MAYMOVE, 0); Whether existing systems make use of this is another matter entirely. My language uses mremap for growth and shrinkage of stacks. C programs can't do it because pointers to stack allocated objects may exist.

simonask 5mo ago
Stack memory is never unmapped until the thread terminates as far as I know. I don’t know of any kernel that does this, for precisely the reason you arrive at by the very last sentence.
- matheusmoreira 5mo ago
  It's just normal pages to the kernel. In theory, it's totally possible for the program to munmap some of its own stack's pages if it was sophisticated enough. Typical C programs just aren't capable of it, at least not without great effort.
dwattttt 5mo ago
> C programs can't do it because pointers to stack allocated objects may exist. They sure shouldn't exist to the unused region of the stack though; if they do, that's a bug (because anything could claim that memory now). You should be free and clear to release stack pages past your current stack pointer.
- simonask 5mo ago
  There isn’t any operating system or compiler that does this today, and it probably isn’t worth it to pursue. Enlarging the stack via page fault is really expensive, so you would need really advanced heuristics to prevent repeatedly unmapping/remapping those pages. The correct tool for myriad of small tasks is coroutines / green threads / async tasks, so why spend any energy optimizing threads for that purpose instead of what they are already good at?
  - dwattttt 5mo ago
    In the general case it's absolutely not worth it. In the context of "you want a large number of OS threads, and are willing to go to some effort", it's theoretically something you'd want to do; suppose the startup for a thread is measurably a high water mark for stack usage, after startup the steady state stack usage won't exceed 20% of that high mark, and you'd like as many threads/stacks as possible. Coroutines / green threads / async tasks will all do this too, but there's something to be said for using/relying on the system scheduler instead of bringing your own in in addition.
- matheusmoreira 5mo ago
  High level languages have entire runtime systems dedicated to managing resources like that. My language can allocate, grow, shrink and deallocate stacks dynamically. It has complete visibility into everything, and the stacks themselves are designed to be relocatable and position-independent. In C it's impossible to even get the stack pointer without dropping to assembly or using compiler builtins. It's hard to know where the stack starts or even how big it is.
  - dwattttt 5mo ago
    I do agree with this, but just to be clear (for others), you don't need any runtime managing resource lifecycles to know that there shouldn't be pointers into free memory, such as the currently unused portion of the stack.