httpd-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Ben Hyde <>
Subject Re: Malloc v.s. pools (was Shared memory in APR.)
Date Thu, 15 Jul 1999 12:28:25 GMT
"Ralf S. Engelschall" <> writes:
> Sorry for the off-topic question: This statement occurs from time to time and
> I was never convinced of its truth - at least not under Unix. Sure, AFAIK
> Opinions?

Pools have better performance that malloc not on the alloc,
but on the free.  Better code size too.  They have nicer semantics 
too since they resolve lossage in malloc's minimalist solution to 
the cleanup problem.

All memory management schemes have attributes...
  1. What heap do they embed within.
  2. Whats the story around Alloc/Free on that boundry.
  3. Whats the story around Alloc/Free on their API.
  4. How do they deal with the gc or fragmentation problem.
  5. What introspection services are available.
  6. What cleanup hooks are provided.

In every system I have build in C in my life we have replaced malloc.
On the one hand low level subsystems with good tiny APIs tend to get 
replaced, it's too much fun to pass up and on the other there is
far too much of a tempting liturature on memory management

I've often wanted better introspection, for example a debug tool that caught
assignment on the margins, or traced who allocated what, or was self
identifing.  I've almost always wanted control of #1 so I can
embed my heap in a file for faster document read/write - the
moment you do that the long term perfection of #4 become much
more serious.

The GC/fragmentation problem tends to be the same one, i.e.
sooner or later the allocator has to tour a large data
structure and condense useful chunks out of useless ones.

But most importantly I have never encountered a malloc implementation
that could be trusted to do #4 over a long period of time.

  - ben

View raw message