Back when I first wrote sl_malloc, the idea was to grow the slab as needed and never have a free() method. Somewhere along the line this idea was shot down and we implemented free() anyway. I believe that was a mistake.
If we get around to reimplementing this in 2.7 or 2.8, or 3.0... There should be these main classes of memory allocations:
1) per-server: this would mostly be config info, and any necessary per-database stuff. Can continue to use chmalloc/chfree.
2) per-connection: not much besides authc/authz. continue to use chmalloc/chfree.
3) per-operation: the BER structures for parsing an incoming request, plus any per-operation handling. This would use the equivalent of the current op->o_tmpmemctx. Would also include ACL cache, which is also relevant to an entire operation.
4) per-message: Only Search requests have multiple response messages. This would primarily be the structures needed to construct a search response. This would be a newly defined slab, which is reset before sending any search response.
5) per-function: Sometimes needed to allocate arrays used to return values from e.g. a normalization function. This would be a newly defined slab. We might continue to avoid the need for this, with the same trick we already use in libldap: do a pre-parse pass where we count the sizes of the values and arrays we need to return, and only allocate them after all sizes are known.
The idea is that in routine operation, there is no need to call any kind of free() function. Just an occasional reset() on some slabs before they get reused.
In practice, free() is more expensive than malloc() because it may have to walk many memory blocks to try to coalesce them, so it's of great benefit to eliminate any need for a free() function.
As for growing the sl_malloc slab dynamically - this would be done without realloc. Instead just use a linked list of slab chunks, and allocate memory from the tail chunk. On slab reset, free all the chunks except for the initial one.