[Haskell-cafe] FPS lib

[John Meacham]

On Thu, Oct 20, 2005 at 09:41:06AM +0100, Simon Marlow wrote:
> [ oops, I meant to send this yesterday but it didn't go out for some
> reason ]
> 
> On 18 October 2005 12:40, Krasimir Angelov wrote:
> 
> >    ForeignPtr requires more memory. Each ForeignPtr has
> > ForeignPtrContents structure attached. In the ForeignPtrContents there
> > is one IORef. Each finalizer adds one Weak# object in the heap. The
> > IORef is a reference to a list of finalizers, so each new finalizer
> > adds a new CONS cell. The finalizers require additional steps in GC
> > time. I haven't tried to measure the difference between ForeignPtr and
> > ByteArray# based implementations but it seems to me that the latter
> > might be better. Of course it will be GHC specific.
> >    mmap is valuable only for large string. Typically only when someone
> > wants to read the entire file in the memory. For this case a special
> > data structure might be provided.
> 
> We can assume that in the packed string case, most of the packed strings
> will be allocated in Haskell, and will therefore be represented by a
> ForeignPtr with a ByteArray# inside - therefore no finalizer, no Weak#
> object, and no cons cells.  
> 
> It is a shame that we need the IORef, but I'm wondering whether we
> should have a special kind of ForeignPtr to which you can't add any more
> finalizers (ie. addForeignPtrFinalizer would fail) to optimise this
> case.  We never need to add any finalizers to packed strings created in
> Haskell.  Also, the IORefs will interact badly with generational GC, so
> we should really get rid of them.
> 
> If we eliminated the IORef, then the difference between ByteArray and
> ForeignPtr would be one word, i.e. negligible.  I think the flexibility
> is worth it.  Also, I bet that you won't find any useful benchmarks in
> which the difference is significant 

I think a lot of benefit can be had by making ForeignPtr a product type
rather than a union one. being able to unbox it in constructors and
opening it to CPR analysis is key for tight inner loop code which
pointers will most definitly be involved in.
        John

-- 
John Meacham - ⑆repetae.net⑆john⑈