efficiency

[Manuel M. T. Chakravarty]

Simon Marlow <simonmar at microsoft.com> wrote,

> The one thing that concerns me is the overhead of the malloc/free for
> allocating the memory into which we marshal structs.  This and the
> overhead of installing an exception handler to free the memory in case
> of an error.
> 
> GHC has ByteArrays which are more efficient (no explicit free, no need
> for an exception handler), but they have the problem that they can move
> around and therefore can only be passed to unsafe foreign calls.
> However, I'd really like a way to integrate them into the current FFI
> scheme.
> 
> An alternative is to write our own memory allocator - we can't use
> thread stacks, because they tend to move around too, but we could use a
> static area of memory allocated in a stack-like fashion.  This won't be
> a huge win over malloc/free though.

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.

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

Cheers,
Manuel