>> What I meant was: surely the stacksize is not really limited, even it it is
>> configured without limits?
unlimited just means that the kernel code responsible for letting
the stack grow will not impose a specific limit until it "runs into"
some other memory allocation...
> I'm wrong here, but I believe the stack is allocated 'upward' from the end
> of where your data/program reside in memory, whereas variables on the heap
> are (or tend to be, in fragmented memories) allocated 'downward' from the
> maximum available free memory. So, at some point, those two will meet if
the opposite, actually. stack is high and grows toward low addresses.
heap grows up from end of text; the mmap arena (which includes shared
libraries) also grows upward.
> ... Bear in mind, my only experience with this is from the old 2.4 series
> kernels, where you had to modify how heap allocations were done in order to
> get above 2GB on 32-bit machines. Given that that's ancient history, things
> may have changed. ;)
yeah, pretty much - text and heap are the same, but the mmap arena
starts at ~182 GB instead of 1 GB. stack starts at (1<<64)-1, so is not
going to collide any time soon...
> allocations can be swapped out to virtual memory, I'm not too sure stack can
> be, as it tends to be faster, and used a bit differently. Anyone know?)
the memory manager just knows pages; it doesn't really care whether
the app thinks of it as stack or heap. (there are properties like
page protection, backing store or grow-down allocation policy...)
regards, mark hahn.