The phenomenon you're referring to is called a stack-heap collision, where one grows so much that it overlaps the other. It's also theoretically possible to have a stack that continues to grow downward as long as memory is available to hold it. Step over that line with a POSIX-y system and you get a segmentation fault. In modern systems, it's usually a soft limit that can be reset before starting the program or while the program is running. Pushing a 257th byte onto the stack would cause the stack pointer to wrap around and clobber the bottom of the stack. Sometimes this is a hard limit, such as on the 6502, which had a 256-byte stack at a fixed location in memory and a one-byte stack pointer. Stack overflow is what happens when an architecture with a bounded stack tries to increment its stack pointer beyond its maximum possible value. Resume: the exact behavior depends a lot on your OS and your compiler, on Linux only the sky it the limit. Fortunately modern compiler optimize this case so we do not have to worry about this so much. Small objects (such as integers, float, doubles) often fit into a register (typically 4 or 8 bytes) or two. Then big objects on the stack must be copied as whole! It is more efficient in both time and space to return a pointer to memory address of the heap instead, which conviently fits inside a register easily. In contrast, creating a variable on stack grows the stack by the same amount.Īssume that you want return your object to the calling function instead. On the other hand using the heap for small objects could invite memory fragmentation (see also Mozilla), this depends a lot on the allocator. Often allocations using heap can be satisfied without growing the heap. Such a hole could for example open when two or more smaller objects, allocated at adjacent addresses have been deallocated. Normally your heap will contain holes: space leftover from objects being deallocated, if you are lucky your new object fits just inside of such hole. Heap on the other hand is typically backed up by virtual memory management which allows it to grow during process life time. Stack can be limited, for example on old OS or in multi-threaded applications each thread might get its own size-limited stack, then allocating big objects on stack might overflow it. Now what happens if we remove these assumptions? To make this choice really symmetric we assume that this holds true when using the heap as well. Objects on the stack are deallocated when the function returns. Your new big object will be added to the end of the heap respective stack. Stack and heap live in the same, fixed process memory region, and there exists no other limitation. (And we are not talking about very big objects that might be better mmap'd and other less common scenarios). You question indicates that you choose between heap or stack, only. Given the assumptions below, yes - does not really matter whether you pile it on the floor or hang it from the ceiling.
0 Comments
Leave a Reply. |