Mark Hahn <[EMAIL PROTECTED]> writes: >>> 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...
Or until it hits an internal limit of some sort. >> 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. That is architecture dependent, though I will admit that most common modern architectures, such as the x86 descended ones, work that way. > yeah, pretty much - text and heap are the same, but the mmap arena > starts at ~182 GB instead of 1 GB. That also depends. You can request mmaps at specific locations, and different operating system variants pick different defaults when you don't request one. > the memory manager just knows pages; it doesn't really care whether > the app thinks of it as stack or heap. Again, not precisely true. Most modern operating systems don't allocate stack pages in advance of use -- they have logic that knows that a region is stack and automatically allocates a new stack page if there is a fault caused by accessing the page past the top of the stack. -- Perry E. Metzger [EMAIL PROTECTED] _______________________________________________ Beowulf mailing list, [email protected] To change your subscription (digest mode or unsubscribe) visit http://www.beowulf.org/mailman/listinfo/beowulf
