Mail Archives: djgpp/1997/03/07/01:38:25
Mark T Logan wrote:
> The only catch is that your manager can't give out addresses when you
> call its
> allocation function. This is because if it goes and collects the
> garbage, all the
> addresses change. So, you have to give out handles. A handle is the
> address
> of a location in memory where you have stored the address of an allocated
> block. This means that your manager has the one and only copy of the
> chunks
> address, and can change the address when it moves a chunk.
In this case you then need lock and unlock functions, to lock down a handle
so that it won't move when you do memory-intensive operations that might
move blocks around in memory.
As a word of warning: This kind of memory management system is only
necessary when you have very limited memory, or if you know that memory
will get completely fragmented with all sorts of varying-size blocks.
What you end up with is something like the Macintosh Memory Manager.
Overall it wasn't a bad idea, but in 1997 it has become almost completely
unnecessary, and has given programmers untold numbers of headaches,
uncurable with aspirin. (And there's the fact that the Macintosh operating
system doesn't handle application memory with this kind of situation, so
while memory won't get fragmented within an application heap zone, it
_will_ get fragmented between them. Ugh.)
The short answer is that a suballocator is usually more than sufficient,
especially when you know that the blocks will all be of a certain size,
which is what the original poster seemed to be needing.
--
Erik Max Francis, &tSftDotIotE / email: max AT alcyone DOT com
Alcyone Systems / web: http://www.alcyone.com/max/
San Jose, California, United States / icbm: 37 20 07 N 121 53 38 W
\
"I am become death, / destroyer of worlds."
/ J. Robert Oppenheimer (quoting legend)
- Raw text -