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. Cheers, Simon
On Mon, 4 Dec 2000, Simon Marlow wrote:
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.
Maybe the storage for use by alloca could be allocated as a linked list of large memory blocks. It should still make use of efficient stack-like allocation within the block.
because I recon eliminating the exception handler is more important than speeding up the actual malloc/free.
Hmm... -- Marcin 'Qrczak' Kowalczyk
participants (2)
-
Marcin 'Qrczak' Kowalczyk -
Simon Marlow