In my experience, it depends. 99% of the time, malloc/free is your best bet: fast enough, battle-tested, everything already uses it, etc.
In the 1%, though, you'll have needs that malloc/free don't fit. Complex object graphs don't really have a single point of ownership or requiring that you free something in all the places that it might be released is too much to handle. In this case you can reach for a garbage collector (including, for example, implementing reference counting). Other times, you may need to make a lot of allocations in a short time where they can all be freed at once. Request processing in a network server is a common example of this: once the request is complete, everything allocated can be dropped, and you generally want minimal latency.
All of this comes with tradeoffs, though. With a GC, you lose predictability and performance changes; sometimes for the better and sometimes for the worse. Depending on the GC, you may not be able to have stable pointers, and you may lose the ability to finalize objects. With an arena, you can't free or reallocate, so you need to scope the arena to a small region of execution (this is where the author went wrong, for example).
Finally, regardless of which approach you use, you're going to need to thread the allocator through the application; probably implement your own datastructures, etc. Depending on how complex your memory management model is, you may need more than one allocator at any given point (e.g., a GC for the persistent data and an arena per connection and per request). If you're implementing your own allocator, you'll also likely have bugs, and allocator bugs tend to be insidious and obnoxious to debug.
If you can avoid going down that route, I recommend it. Sometimes, though, you have enough constraints that you need to brave the jungle.
Itanium has well over a kilobyte of general-purpose registers. That's lovely for single-process performance, but it absolutely slaughtered context switch time given the available memory bandwidth at the time. On top of that, it was fiendishly difficult to actually find instructions that could fill the instruction stream, and thus i-cache utilization was a disaster. On top of all of that, it exposed far too much microarchitecture to userspace: it would forever be pinned to having three execution ports with very specific capabilities, and any changes to the µarch would have resulted in all of the complicated register rename and instruction scheduling hardware that VLIW was supposed to avoid.
I'll grant that it seemed like a decent idea at the time, but there was enough risk there that I can only describe Intel's all-in stance on Itanium to have been a blunder.
(There's a worthwhile distinction to be made between a blunder and a mistake. Mistakes are calculated risks that don't pan out, whereas a blunders is something that should have been obvious that it would go poorly when the decision was made. Losing your savings in the stock market from a surprise dip is a mistake. Losing your savings by betting it all on 14 in Vegas is a blunder. Similarly, the design of Itanium was a mistake. Betting the company on it was a blunder.)
As pjmlp points out we don't know what would have happened if Intel had spent another few billion dollars re-implementing IA64 in a lower cost / lower power form. To me one of the big lessons of the last few decades is that pragmatic microarch has convergent evolution due to the same underlying constraints of expensive memory access, clock speed scaling limits, general non-determinism of everything surrounding the core, etc, and within reason the ISA will end up conformed to those limits in a way that makes the initial ideology (RISC, CISC, VLIW) not so important. For example RISC is simple, except once you mix OoO, compressed instructions, macro op fusion, etc, those all have externally visible effects so c'est la vie simplicity.
One can imagine an evolution of IA64 that conceded microarchitectural complexity to allow adoption of a more compact instruction format with dependency tags rather than fixed bundle width, resulting in something more like an evolution of P6 with a different face, better x86 compatibility, and still ISA uniformity with the big iron. Or an evolution that involved buying Transmeta and adding IA64 support to that.
Obviously Intel didn't end up doing any of these things, probably because distribution strength and process superiority allowed them to do less and still post strong quarterly numbers. I'm not even sure if it was a blunder given the local incentives of the people who worked there at the time.
Don't underestimate the importance of a pen, ink, and paper you like. I found my pen a decade ago: Lamy Studio, in British Racing Green, with a medium nib. I found my ink not long after, from J Herbin's collection.
It wasn't until I got a nice notebook from Leuchtturm 1917, though, that the ensemble came together and I started looking for excuses to get my kit out and write things down. Since then, I've moved onto notebooks from de Kempen, but the point stands
A nice pen is... nice. But it's as easy to fall into geeking out about pens and paper as it is keyboards, knives and other kitchen utensils, tools, etc. In most cases, any pen is as good as any other. Or just find a cheap mass produced pen that feels good in your hand. They are plentiful. Then buy a stock of them.
I actually like using pencils, with a thick lead because I tend to have a pretty heavy hand when writing and I will continually break a thin lead.
In the 1%, though, you'll have needs that malloc/free don't fit. Complex object graphs don't really have a single point of ownership or requiring that you free something in all the places that it might be released is too much to handle. In this case you can reach for a garbage collector (including, for example, implementing reference counting). Other times, you may need to make a lot of allocations in a short time where they can all be freed at once. Request processing in a network server is a common example of this: once the request is complete, everything allocated can be dropped, and you generally want minimal latency.
All of this comes with tradeoffs, though. With a GC, you lose predictability and performance changes; sometimes for the better and sometimes for the worse. Depending on the GC, you may not be able to have stable pointers, and you may lose the ability to finalize objects. With an arena, you can't free or reallocate, so you need to scope the arena to a small region of execution (this is where the author went wrong, for example).
Finally, regardless of which approach you use, you're going to need to thread the allocator through the application; probably implement your own datastructures, etc. Depending on how complex your memory management model is, you may need more than one allocator at any given point (e.g., a GC for the persistent data and an arena per connection and per request). If you're implementing your own allocator, you'll also likely have bugs, and allocator bugs tend to be insidious and obnoxious to debug.
If you can avoid going down that route, I recommend it. Sometimes, though, you have enough constraints that you need to brave the jungle.
reply