Hacker News Reader

Comment by digeridoo | Hacker News Reader

> today’s programmer can even go so far as to question the usage of malloc

In old school or new school C, there's every reason to minimize the use of malloc and it's easy to avoid.

Do give the top 5 list of such reasons.

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.

Even with a virtual memory addressing system, fragmentation still leads to space wasted. IIRC, fragmentation was one of the reasons firefox had reaaaally bad memory usage: http://pavlovdotnet.wordpress.com/2007/11/10/memory-fragment...

Is it really down to you remembering correctly if you have a blog post to link to? :P

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.

The pseudo-C used in the Quake 3 VM had no malloc()[0] and they wrote a frigging AAA game with it. I suggest you check out their source code[1].

[0] http://wiki.ioquake3.org/Getting_the_most_from_Quake3_C#No_M... [1] https://github.com/id-Software/Quake-III-Arena

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

-http://syncfin.com

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.

> Do give the top 5 list of such reasons.

This is a waste of time.

We all need to start evaluating the problem, taking account for the environment, and use the language that gets the job done.

Reply on news.ycombinator.com