slapd memory management revisited

Howard Chu <[email protected]> Mon, 9 Feb 2026 18:03:33 +0000
Newsgroups gmane.network.openldap.devel
Message-ID <[email protected]>
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.

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