I've noticed that every running C program has a private mapping called [stack] that is initially quite small (128k on my machine), but will grow to accomodate any automatic variables (up to the stack size limit). I assume this is where the call stack of my program is located.
However, it doesn't seem to ever shrink back to its original size. Is there any way to free up that memory without terminating the process?
How is the C stack implemented internally; what increases the size of the [stack] mapping on demand? Some compiler generated code, the C library or the operating system? Where is the increase triggered?
Update: I'm using Linux 3.0.0, gcc 4.6.1 and glibc6 on x86-64; as this is probably pretty implementation specific, any information on how it works there would be fine.
It's implementation specific, but I know of no commonly used platform which shrinks committed stack memory. It is common for stacks to grow on demand but once space is committed it stays committed.
I believe that the Linux kernel is growing the stack segment (only for the main thread). It is not in the compiler (except by incrementing the stack pointer at calls, and ignoring the experimental -fsplit-stack
option of recent GCC), and not in the libC.
If you are sure your stack has grown too big, and you won't need it, you might perhaps munmap
the unused part (but be careful; kernel developers don't think of this so it might not work as expected; in the early 1990-s I remembered having crashed SunOS5.0 on Sparc with such dirty tricks).
And on Linux, x86-64, with a decent machine, you really should not care. The stack is not that big...
My guess is that the stack segment is mmap
-ed with MAP_NORESERVE
MAP_STACK
MAP_GROWSDOWN
but I may be wrong.
If you love us? You can donate to us via Paypal or buy me a coffee so we can maintain and grow! Thank you!
Donate Us With