Nicholas Clark wrote:
> On Wed, Oct 02, 2002 at 02:01:48PM +0200, Leopold Toetsch wrote:
>>+ if (buffer->bufstart && !(buffer->flags &
>>+ (BUFFER_COW_FLAG|BUFFER_external_FLAG))) {
>>+ free(buffer->bufstart);
>>+ }
> The article doesn't mention garbage collection at all, and neither your
> remarks nor your patch explains how it is now done. Is all garbage being
> collected via that one free(buffer->bufstart); in the patch above?
On the surface, yes that's the whole GC. In realiter it continues inside
the Lea allocator which:
- keeps 128 free lists of different sized pieces of blocks
- coalesces adjacent pieces if possible
- returns these pieces FIFO to the next {re,m}alloc
giving a defragmentation of ~3% in my tests. So there is no need for
copying live chunks around.
> I'm confused, and would appreciate hints about how to become less confused.
From malloc.c:
This is not the fastest, most space-conserving, most portable, or
most tunable malloc ever written. However it is among the fastest
while also being among the most space-conserving, portable and tunable.
Consistent balance across these factors results in a good general-purpose
allocator for malloc-intensive programs.
The main properties of the algorithms are:
* For large (>= 512 bytes) requests, it is a pure best-fit allocator,
with ties normally decided via FIFO (i.e. least recently used).
* For small (<= 64 bytes by default) requests, it is a caching
allocator, that maintains pools of quickly recycled chunks.
* In between, and for combinations of large and small requests, it does
the best it can trying to meet both goals at once.
* For very large requests (>= 128KB by default), it relies on system
memory mapping facilities, if supported.
For a longer but slightly out of date high-level description, see
http://gee.cs.oswego.edu/dl/html/malloc.html
What about reading this page and downloading the file ;-)
> Nicholas Clark
leo
