Cheap ForeignPtr allocation

[Alastair Reid]

> Nevertheless, I think even without the tricks I'm using in GHC, the
> case where a ForeignPtr is used in conjunction with malloc()/free()
> is one which is likely to be optimisable in any system with its own
> memory management.

I wasn't meaning so much that only GHC could take advantage of it
(though I think that is true at present) but that someone might come
along next week with a technique which avoids the problem altogether.

> [...] using a ForeignPtr here, with free() as its finalizer, adds so
> much overhead that [...]

Where is the overhead coming from?  Is it the cost of a C call or the
cost of the standard malloc library?  If the latter, I imagine that a
custom allocator would have similar performance to using pinned
objects.  (I'm sort of assuming that pinned objects are more expensive
than normal objects.)

btw I don't know if it's relevant but there's an important semantic
difference between allocating on the GHC heap and allocating on the C
heap.  The C version can be manipulated by the malloc.h functions.  In
particular, you can call realloc on it.  Do that on the GHC heap
version and... well, it won't be pretty.  I don't know if this is
relevant because using realloc with ForeignPtr'd memory is likely to
be a delicate procedure no matter how it got allocated.

-- 
Alastair