httpd-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Ambarish Malpani <>
Subject Re: Making pool allocation functions smarter
Date Thu, 26 Jun 1997 18:42:39 GMT
Hi Rasmus,
    Did something like this in a previous life. The way I did it
was slightly different. Here goes (and some of the reasons why):

Pools are meant to be used where you want to do a bunch of fast
allocations for lots of (mostly) little chunks of memory and where
you know the life of these chunks is limited, so you don't want to
go through a complicated procedure to free all of them - and you
don't want to need to worry about memory leaks.

When you are proposing to keep lists of free memory and allocate
an appropriate buffer from the free list, keep track of the buffer
size, (and potentially merge consecutive freed buffers), you are
doing a lot of the work that malloc does (except that a user
can still free everything at one shot).

What I had done (because it pained me, too, to see these little blocks
of free memory lying around unused ;->), is, I put a restriction
that the pool would NOT try and merge adjacent blocks or do very
complicated things. When you ask a pool for some memory, it will
check its free list for a block of the precise size that you
requested. If it can find one, it will give that back to you. If
it can't, it will behave like its free list was empty and give you
the memory like the pool does today. (no searching for best fits etc.)
Also, because I did not want the memory overhead of keeping track of
the size of pieces allocated from a pool (because people make a lot
of allocations of small pieces), I required a user to specify the
size of the piece he was trying to free and the pool it originally
came from.

This simplifies the problem of keeping track of the freed blocks.
Also allocations can still be very, very fast (because you keep the
freed blocks as multiple lists, each of a particular size) and it
works very well in cases where you keep allocating and freeing blocks
of the same size (most data structures have a fixed size - the
main place where you have problems is with strings).

Unfortunately, I can't give you all the code (since I had done this
work at a previous company and that was all propietary stuff), but
if you and the group is still interested, I know I want to add the
stuff to my own library, so I could develop it again....

Let me know what you think,
A wrote:
> > block A      block B    block C
> > ***---**---  ******--   ******----
> >
> > block A      block A1   block A2   block B   block C
> > ***          ---        **---      *****--   ******----
> I guess where the simplicity of my suggested solution falls apart is that
> we do not track the size of individual chunks within a block.  I wouldn't
> be able to determine where block A2 should start without adding some
> additional logic and chunk size tracking code.
> -Rasmus


Ambarish Malpani
Architect					       (408) 738-2040
ValiCert, Inc.
333 W. El Camino Real, Suite 270
Sunnyvale, CA 94087

View raw message