I'll give one for old-school: heap fragmentation. You can't fragment a stack, block allocators have predetermined fragmentation behavior, heap is "who knows" It is possible to malloc() and free() for a very small net-total, and yet be no longer able to allocate a contiguous region that is a significant fraction of the heap.
With a modern VM system, it's not quite as big a deal since your heap is effectively infinite for many applications. It is still an issue on embedded systems, and was a problem back in the day too.
Question from a newbie C developer: How can you avoid using malloc? Are you finding some clever way to do everything on the stack? Or are you perhaps allocating a large block of contiguous memory and slicing it up on your own?
I've heard of both of those approaches and they sound pretty hard, so I'd be interested to hear your thoughts/be pointed to good references on the topic. Thanks in advance.
A lot of the time, the nature of the data and its lifetime makes specialized allocators easy to use. Not infrequently they can actually be more convenient than malloc/free when you have a bunch of allocations (think nodes in a parse tree) with the same lifetime, so their storage can be released as a single operation. For that example, you can get the same usability with a more traditional malloc/free interface using something like hmalloc, but if the parse tree nodes all occupy the same contiguous block, you get it automatically. And of course it's a lot faster to release a single block (if you release the storage back to the OS, the page manager will still have some per-page work for a virtually contiguous block of memory).
Basically, once you have a nailed down system design, it's usually not any significant extra work to use custom allocators. Where it can suck away your productivity is during iterative design and development where you're still figuring out the different kinds of data, what subsystems exist and who owns what when. But in that scenario, garbage collection is even easier than malloc/free, so it's not a mortal sin to use Bochs or just leak memory (heresy!) if you can get away with it--only temporarily, of course, while you figure out the design.
There's a large block of memory that's easy to slice up on your own. It's called the BSS section, which is where global and static variables without an initial value are stored. BSS gets zeroed before main() is called.
This isn't possible in all cases, but for embedded software especially it's often possible to create all data structures as global or static variables. The compiler takes care of alignment concerns for you, and you're guaranteed not to have heap issues because you never use the heap. Of course, you can run out of the objects you pre-allocated in BSS, but that's an easier problem to diagnose and fix.
1. Most of the compilers restrict the size of Stack to be much less than the size of heap.
2. If you use the space of this stack for dynamic memory allocation as well, you will be limiting your capacity to write recursive functions.
3. it will depend on the kind of system you are developing. If you are developing some tool to analyze millions of tweets, you have to use "heap" there is no alternate. If you are developing an embedded application " say loading your list of conatcts for sending the message yes there you can get away with allocating the memory on stack itself. But then there most of the phones do not allow you to make a list of more than 25-30 people.
So it depends on the application one is willing to develop and K&R well recognized it in early 70s itself that is why they introduced alloca in addition to malloc , calloc
I never said you should put everything on the C stack. I also never said you couldn't use dynamic memory. You can have a custom stack or block allocator with memory coming from sbrk() mmap() or preallocated in the bss.
With a modern VM system, it's not quite as big a deal since your heap is effectively infinite for many applications. It is still an issue on embedded systems, and was a problem back in the day too.