The only real way to prevent allocation fragmentation is to move
blocks of memory around - i.e., return and manilpulate handles to 
pointers instead of the pointers themselves. But this adds a lot
of runtime overhead and is not C friendly.
Anything else is just a compromise. Predictive and statistical 
schemes only go so far. You still get fragmentation.
Maybe if you had special logic for moving and compacting the db
page cache memory, that might be sufficient.

Anyway, it's interesting stuff. I'm curious as to what solution
you'll have.

--- [EMAIL PROTECTED] wrote:
> 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]>


__________________________________________________
Do You Yahoo!?
Tired of spam?  Yahoo! Mail has the best spam protection around 
http://mail.yahoo.com 

-----------------------------------------------------------------------------
To unsubscribe, send email to [EMAIL PROTECTED]
-----------------------------------------------------------------------------

Reply via email to