[EMAIL PROTECTED] wrote:
Joe Wilson <[EMAIL PROTECTED]> wrote:
The only real way to prevent allocation fragmentation is to move
blocks of memory around -
Not true. You can prevent fragmentation, for example, by
not allocating objects beside each other that will be destroyed
at different times. Or, you can pick a single allocation size
and only do mallocs of exactly that size. The latter approach
is what we are moving towards for SQLite. The allocation size
would be the size of what Emery calls a "reap". If you deal
with large strings and blobs you might need to allocate a chunk
of memory larger than this, which destroys your fragmentation
guarantees. But at least you can write testable requirements
about when you guarantee that fragmentation will not occur.
You are correct that avoiding fragmentation is very difficult.
But is also very important for some users and it is thus
something we want to be able to provide.
--
D. Richard Hipp <[EMAIL PROTECTED]>
Great foresight. Programs which should run unattended but fail from
time to time by running out of heap are a nuisance.
We had some success by allocating memory in fixed size chunks which have
optional smaller chunks internally. Fragmentation of the checker board
type is avoided at the expense of sub-optimal packing. The large chunk
is sized to fit the biggest dynamically allocated object. The chunks
are contiguous.
On portable software which cannot tolerate fragmentation and has a
limited number of dynamically allocated types avoiding free and using a
free list for each type is very robust. Lurking problems caused by
squirrelly mallocs are avoided. After running for a few months a high
water point in memory is established and memory usage does not creep
thereafter.
-----------------------------------------------------------------------------
To unsubscribe, send email to [EMAIL PROTECTED]
-----------------------------------------------------------------------------
