RE: Thread-local malloc discussion summary

["Howard Chu" <hyc@highlandsun.com>]

> -----Original Message-----
> From: owner-openldap-devel@OpenLDAP.org
> [mailto:owner-openldap-devel@OpenLDAP.org]On Behalf Of Jonghyuk Choi

> 3) a special per-thread preallocation for an operation's lifetime
>    where mallocs for selected objects of the operation are satisfied
>    from the preallocated chunk. Free of such objects can be a no-op.
>    When the opeartion finishes, the preallocated chunk can either be
>    reset for use in the next operation or be freed.
>
> The current CVS HEAD is implementing the last approach
> for the search operation. The most frequently executed malloc
> invocations are being investigated for a possible change
> to use the new thread-local malloc routine. For operations
> such as add / modify (also psearch), the amount of
> memory allocated during the operation may grow large when
> the size of entry / modlist is unbounded.
>
> Design issues on the add/modify operations, the choice of objects,
> API changes requires further discussion in the community.

I had hoped that search could be adapted without impacting a lot of other
code, but it dragged out to more than I expected. The current arrangement is
troublesome due to the need to keep global heap allocs separate from
thread-local allocs. We can allow some sloppiness here by changing the
sl_realloc and sl_free functions to simply pass through to ch_realloc and
ch_free if the passed-in pointer does not reside in the thread-local space.
I'd like to see some profile results showing the current version's
effectiveness before pursuing this any further. Certainly it is a bit faster,
but it's also harder to use...

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