Joe Wilson <[EMAIL PROTECTED]> wrote: > Hi Richard, > > This might be worth a read. This paper discusses limitations of custom > memory allocators: > > Reconsidering Custom Memory Allocation > http://www.cs.umass.edu/~emery/pubs/berger-oopsla2002.pdf >
Interesting paper. Thanks for the link. I have not read it yet, but a quick scan shows that Emery completely overlooks one of the key reason I am experiementing with memory pools: provable correctness. General purpose allocator, such as Doug Lea's, do an excellent job of preventing and dealing with memory fragmentation. But they do not (can not) guarantee that memory will never fragment. We are working on techniques that will guarantee that the heap will not fragment. And in order to achieve that, we need very low-level control of the memory allocation. Hence my recent interest in memory pools. There is also quite a bit of interest in this research from people using SQLite in embedded machines with bad malloc() implementations (and, I am told, compelling reasons why they cannot just substitute a better malloc.) Emery's observation that memory pools will not magically cure the performance problems of a legacy application is quite correct. You cannot just take any old application that uses malloc, stick memory pools underneath it, and expect it to work well. Hence, we are also reworking the upper layers of SQLite to know that they are using memory pools and to use those pools effectively. -- D. Richard Hipp <[EMAIL PROTECTED]> ----------------------------------------------------------------------------- To unsubscribe, send email to [EMAIL PROTECTED] -----------------------------------------------------------------------------
