Re: slap_sl_malloc

[Howard Chu <hyc@symas.com>]

Jong-Hyuk 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 changed syncrepl to use ch_malloc to suppress those messages for now.
>
>  
I was actually thinking of adding a config keyword to enable/disable 
sl_malloc, and replacing all the direct calls in the source with calls 
thru the sl_mfuncs structure. Then most of its functionality can be 
toggled just by changing that single structure. This would make testing 
for memleaks a bit easier.

--
 -- Howard Chu
 Chief Architect, Symas Corp.       Director, Highland Sun
 http://www.symas.com               http://highlandsun.com/hyc
 Symas: Premier OpenSource Development and Support