Re: (ITS#6437) sl_malloc issues

[hyc@symas.com]

Hallvard B Furuseth wrote:
> hyc@symas.com writes:
>> Nobody uses the pool code. I would suggest you profile it against the stack 
>> code before spending any time fixing it.
> 
> The pool version crashes if I divide SLAP_SLAB_SIZE by 16 or multiply
> the allocated amounts by 17.  The stack version stays happy.  I also
> tried RE23 and rev 1.48 in case of code rot.  (Should have tried
> OpenLDAP 2.2, but would need to install an old Berkeley DB.)  Adding a
> sl_malloc fallback to ch_malloc instead of returning NULL didn't help.
> 
> Anyway, I tried this because I assume the pool version is intended to
> reduce the number of sl_malloc fallbacks to ch_malloc, but that almost
> never happens in 'make test' with the current SLAP_SLAB_SIZE.  Which
> made that aspect hard to test.
> 
> Also the pool version does a number of ch_mallocs for administration and
> ch_frees them at reset. If the idea is to reduce ch_mallocs, it should
> keep these blocks around.  (Or allocate them with the slab.)  Except the
> 'slab_object's It only needs cleanup if the slab size changes, which
> slapd never seems to do.

This stuff was originally written to grow the slab as needed, but it was also
being very braindead and would have kept a lot of excess memory lying around
so I dropped that. So right, currently the slab size doesn't change.

-- 
  -- Howard Chu
  CTO, Symas Corp.           http://www.symas.com
  Director, Highland Sun     http://highlandsun.com/hyc/
  Chief Architect, OpenLDAP  http://www.openldap.org/project/