simonmar at microsoft.com
Mon Dec 4 05:46:12 EST 2000
> This is also my main efficiency concern. Would it be an
> option to handle thread stacks differently in the memory
> manager? Apart from them moving around, thread stacks are
> the natural place to get alloca memory from.
Thread stacks fall into the category of "large objects" in GHC's storage
manager, and therefore aren't normally moved. However, they have to be
able to grow on demand, so we occasionally have to relocate them. I
suppose we could pre-allocate large stacks if we were planning on doing
any static stack allocation, but that seems to be a particularly
overgrown path to be wondering down.
> I am not sure why you are saying that a static area of
> memory allocated in a stack discipline wouldn't be a huge
> win? It would ceratinly get rid of the free list handling
> of malloc/free. As for exceptions, I am not familiar enough
> with their implementation. But we might have to have such
> an area per thread...
because I recon eliminating the exception handler is more important than
speeding up the actual malloc/free. No figures, just compiler hacker's
instinct :) You wouldn't be able to eliminate the exception handler if
the allocation were done in a separate static area, even if it was
allocated stackwise. We've been talking about speeding up catch (and
block/unblock) for a while, but haven't done anything yet.
More information about the FFI