Re: Thread-local malloc discussion summary

[Matthew Backes <lucca@csun.edu>]

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
lucca@csun.edu