write my own memory manager [closed]

Question

As it currently stands, this question is not a good fit for our Q&A format. We expect answers to be supported by facts, references, or expertise, but this question will likely solicit debate, arguments, polling, or extended discussion. If you feel that this question can be improved and possibly reopened, visit the help center for guidance.

Closed 9 years ago.

I would like to allot some huge dynamic memory and then write my own memory manager for it. i.e. As and when my code needs memory, I'd allot from this pool of memory. I want the algorithm to take care of internal and external fragmentation. Which is the most efficient algorithm for this?

Answer 1

For these criteria I'd go with Doug Lea's http://g.oswego.edu/dl/html/malloc.html, which maintains collections of blocks of store for each of a number of different sizes - it's quick to find the size you need, and reusing blocks of the same size reduces fragmentation. Note (http://entland.homelinux.com/blog/2008/08/19/practical-efficient-memory-management/) that this is NOT tuned for multi-threading.

If I was writing one myself I'd go for the http://en.wikipedia.org/wiki/Buddy_memory_allocation because it's fast and not commonly used in user space (not commonly used because it restricts the possible block sizes, leading to internal fragmentation). In fact, I did, some time ago - http://www.mcdowella.demon.co.uk/buddy.html

Answer 2

This question is amiguous because the term "most efficient" is not clear. You don't say in what terms it should be most efficient.

As an example: There is a strategy called first fit which might be faster than best fit but could lead to more out fragmenetation of the heap (a really bad thing). Best fit on the other hand reduces somewhat the outer fragmentation but still suffers from it while finding a chunk of free memory takes more time. There is also a strategy called buddy heap where you don't suffer from outer fragmentation but from inner fragmentation. But at least finding a free block is usually fast there.

You see choosing an algorithm really depends on your requirements. Should the allocation be fast or the fragmentation low? What's the allocation behavior? Are there small uneven chunks allocated and freed frequently or only big chunks? And there are even more factors playing a role here.

Maybe you wanted an answer like this. If not I recommend you clearify your requirements.