[Date Prev][Date Next]
[Chronological]
[Thread]
[Top]
Re: slap_sl_malloc
At 05:56 PM 8/28/2004, Howard Chu wrote:
>While I would hate to slow this thing down, it appears we may need to use a smarter algorithm here. Currently sl_malloc acts like a stack, objects must be freed in reverse order of allocation otherwise they remain allocated. I'm seeing a lot of "sl_malloc of XX bytes failed, using ch_malloc" log messages while watching syncrepl do its thing, which implies that there is a leak, or objects are not being freed in the correct order.
>
>I'm not entirely sure there's a leak. But it's very likely that things aren't being freed in order, and it's difficult to verify a proper order now. Which implies that we maybe want sl_malloc/sl_free to keep a free list, coalesce blocks, etc., etc. - all the things a real malloc routine does.
I rather reuse an existing, decent, thread-aware allocator
than write our own...
Kurt