hi ,
I am not sure but I think it might be to avoid heap fragmentation due
to several malloc calls. Are there any strong reason ? What are the
other things that should take care when we implement a memory manager ,
like i) garabage collector kind of thing , ii) Safe Free of pointer in
wrapper of Free functions etc .
malloc() itself has a very "narrow" interface: You
tell it the number of bytes you want, but nothing about
what you intend to do with the memory, how long you intend
to retain it, what other chunks of memory it might be
related to, and so on.
A memory manager with more knowledge of the project's
data structures may be able to do better, even if it uses
plain malloc() to obtain the memory that it then doles out
to the higher-level code. Instead of just saying "Please
give me forty bytes," your program can now say "Please give
me memory for a `struct node' that will become part of the
tree whose root is `*rootptr'." Or it might say "Please
give me a hundred bytes for a short-lived buffer that I
may need to expand before discarding." Or it might say
"Please give me a thousand bytes for long-lived storage
whose size will never change." A memory manager armed
with extra information of this sort could do things like
try to keep the nodes of a particular tree close to each
other to minimize page faults, or segregate long-lived and
short-lived data, and so on.
Wholesale operations are also possible. To free all
the memory of an enormous tree, you might just say "Please
release all the memory belonging to pool T" instead of
traversing the whole tree and freeing each node separately.
A project-specific memory manager may be able to offer
additional services beyond pure memory management, too.
For example, let's think of that tree again: Perhaps your
program might need to visit every node of the tree as part
of some operation, but might not care what order they're
visited in. Instead of following the tree's own structure,
possibly hopping from page to page in erratic fashion and
putting stress on various hardware caches, a program that
has allocated all the tree's nodes from a "pool" associated
with the tree might say "Please visit all the allocated
nodes of pool T in an arbitrary memory-efficient order,
calling function f() for each node that's in use."
... and so on, and so on. Different projects have
different needs, and some (particularly those that use
large amounts of memory) can benefit from memory managers
that "know more" about the project's data structures than
malloc()'s simple interface can convey.
