[Date Prev][Date Next] [Chronological] [Thread] [Top]

Re: Thread-local malloc discussion summary

On Wednesday, April 9, 2003, at 04:01 PM, Howard Chu wrote:

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...

Does it make sense to start separating allocations into separate types so that they might be (eventually) implemented differently on different platforms? Some allocations need to be global, some can be within a thread, and many could probably benefit from stack- allocation. Implemented using #defines for example. Environments with a working alloca() could then use it. (with no-op for the free) Environments without it would fall back to a malloc() or thread- local system and still have the appropriate free() call when needed.

I think you've mentioned that getting autoconf to reliably state
whether alloca is usable is tricky.  This shouldn't be a problem
as we can just enable it for specific architectures that are known
to support it.

Matthew Backes