RFC on mt_allocator.h

[Felix Yen]

Benjamin Kosnik writes:
 >  Please, I beg you, document this allocator.

I also beg.  I'm new here, so let me introduce myself.

About two years ago, I was working on a communications server that had  
a memory-related performance problem.  We fixed it by switching from  
the default (Microsoft) allocator to Hoard  
(http://www.cs.umass.edu/~emery/hoard/).  I felt that there was room  
for further improvement in this area, and developed a recycling  
allocator that's part of the server today.  Each server process can  
support 100,000 clients.

After losing my job and taking some time off, I thought it would be fun  
to develop a more generic, open-source version of this allocator, so I  
performed another cursory literature search, and discovered the GNU  
pool allocator.  I subscribed to this mailing list in 8/03 to learn  
more about GNU allocator development.  (I have to say that I am  
extremely impressed by the way engineers collaborate on this project.   
Yours is a model of professionalism that I wish my previous managers  
had known about.)

A month later, I published my allocator in comp.lang.c++.moderated  
(http://home.earthlink.net/~brimar/yalloc/).  I wasn't bothered by the  
lack of response, because free software rarely deserves anyone's  
attention and this allocator is highly specialized.  On the other hand,  
I was quite annoyed when I discovered that I had overlooked significant  
developments conducted by Jeff Bonwick.  In 1994, he published an  
allocator that's similar to mine, and in 2001, he (and Jonathan Adams)  
extended this work to produce an allocator that is *very* similar to  
mine:  
http://www.usenix.org/publications/library/proceedings/usenix01/ 
full_papers/bonwick/bonwick_html/index.html.  (There are significant  
differences, but I don't understand them and have no way of comparing  
performance.)

The point that I am trying to convey here is that allocator development  
is a popular exercise, and one that lacks a well-publicized  
documentation base so there's a lot of duplication of effort and  
second-rate work.  If you doubt my last claim, please read  
"Reconsidering Custom Memory Allocation" by Berger et al  
(http://www.cs.umass.edu/~emery/pubs/berger-oopsla2002.pdf).  Worth  
noting: Bonwick's 2001 allocator comparison includes Hoard, whereas  
Berger never refers to Bonwick's work.  Guess which allocator won the  
comparison?  </intro>

At the very least, an allocator as sophisticated as the one you're  
discussing should be accompanied by documentation that specifies its  
intended applications and describes its design as well as its  
limitations.  I would also like to see a brief description of the  
performance test(s) used to qualify the allocator.  I realize that this  
is a tall order, but any sane person who's shopping for an allocator is  
going to look at GCC sooner or later.

I know someone on this mailing list made the point that the default  
allocator should perform reasonably well in most cases.  I strongly  
agree.  In fact, I think the distribution only has to provide obvious  
alternatives like the version that supports debugging, allocators that  
are used by the distribution itself, and maybe adaptors that facilitate  
using user-supplied classes or global functions as STL allocators.   
Since everyone seems to think that they're better off writing their  
own, let them.


Felix