Re: [AOLSERVER] Leaky AS/Tcl memory allocator

[Jim Davidson]

In a message dated 4/6/05 1:44:46 PM, [EMAIL PROTECTED] writes:

OK. Now, please, whoever wrote this "zippy" (whatever that means) can
you
please see what is going on? Or at least give me some hint where to
start
digging. I need to get rid of this "side effect"....

Hi,

I wrote zippy and zippy means fast.  The code is actually a per-thread adaptation of the old Tcl memory allocator that had been used in the past in certain cases, e.g., on the old Mac platform.

I don't believe zippy is technically leaking memory but it will lead to bloat as it's primary goal, in fact it's only goal, is lock contention avoidance.  This means per-thread pools are spun up for all small allocations.  When threads exit, they transfer remaining blocks to the "shared" pool.  However, any tracking of original source of allocation is not maintained so there is no means to coalesce previous blocks and free large chunks which were originally chopped up for the various blocks sizes.

The example above is the sort that would lead to fragmentation, many short lived threads which lead to short-live per-thread pools.  Things should eventually stabilize as the shared pool is filled with blocks from previous threads.  Of course there could be a leak somewhere but the code has been pretty stable and technically leak free for some time.  Going forward, there are likley newer options such as the google allocator which is similar to zippy for small blocks but appears to be smarter for large blocks and/or garbage collection.

-Jim
2">