Proposal: Pooled memory management

[Simon Marlow]

> Manuel wrote:
> > [...]
> > * I want to get v1.0 of the spec fixed.  We are really only
> >   in bug fix mode for quite a while and only the finalizer
> >   problems held us back from finishing the spec.
> 
> That's OK and I understand your motivation. Let's finish v1.0 first.

I agree, but I don't have any problem with forking the spec at this
point.  The changes to the current 1.0 RC are going to be very small
from now on.

> In a nutshell: Let's include as many useful "patterns" in the 
> next FFI spec
> versions as possible! Otherwise we might talk the same 
> language without recognizing it...

So we might well ask what useful new functionality is provided by a
pool-style memory manager.

One feature is performance: compared to using malloc/free, a pool is
going to be much cheaper.  But I'd be interested to compare the
performance you get from using pools to GHC's implementation of
mallocForeignPtr, which also sidesteps malloc/free to get decent
performance.

Compared to mallocForeignPtr, there are some qualitative differences
which might make one or the other more convenient in some situations:

  - mallocForeignPtr provides garbage-collected storage.  No need
    to free the storage later.

  - However, you do need to use withForeignPtr to get access to the
    object.  This can be quite annoying.

So, assuming the performance is roughly the same (I'm guessing that
using pools may be slightly faster than mallocForeignPtr, but not
significantly), do people see any other compelling reasons to be using
pools?

GHC's runtime has an Arena abstraction which is an implementation of
pool-style memory management, and could be used to implement Pools, BTW.

Cheers,
	Simon