Why do we put GMP allocations on GHC heaps?

[Simon Peyton-Jones]

| This is true, but I would add that C finalizers are rather more prompt
| and reliable than Haskell finalizers, since we added special support for
| them a couple of versions ago.  C finalizers are run directly by the GC
| rather than in separate threads, and we run all the outstanding ones
| before the program terminates.

Great.  Is this difference documented?  I couldn't find my way to this info. 

I tried Hoogling for "final", and got this link
http://hackage.haskell.org/package/base-4.6.0.1/docs/Foreign-ForeignPtr.html#v:addForeignPtrFinalizer
but it is dead.

I wonder if it would be worth summarising in the user manual the main facilities offered, with pointers to the Haddock docs that describe them?

Simon

| -----Original Message-----
| From: ghc-devs [mailto:ghc-devs-bounces at haskell.org] On Behalf Of Simon
| Marlow
| Sent: 24 October 2013 09:24
| To: Bryan O'Sullivan; Gergely Risko
| Cc: ghc-devs at haskell.org
| Subject: Re: Why do we put GMP allocations on GHC heaps?
| 
| On 23/10/13 17:08, Bryan O'Sullivan wrote:
| >
| > On Wed, Oct 23, 2013 at 4:31 AM, Gergely Risko <gergely at risko.hu
| > <mailto:gergely at risko.hu>> wrote:
| >
| >     I can understand that this may be slower in CPU, but can you
| please
| >     elaborate why would it be worse in memory, how the frees wouldn't
| happen
| >     in a "timely manner"?  I thought finalisers are called when the
| >     referencee is GCd, so if we free the mpz in the callback, then
| where are
| >     we going wrong?
| >
| >
| > There is no guarantee that finalizers will be called at all, much less
| > that they will be called in a timely manner. This is a general and
| > well-known property of all garbage collectors, not something unique to
| GHC.
| 
| This is true, but I would add that C finalizers are rather more prompt
| and reliable than Haskell finalizers, since we added special support for
| them a couple of versions ago.  C finalizers are run directly by the GC
| rather than in separate threads, and we run all the outstanding ones
| before the program terminates.
| 
| Cheers,
| 	Simon
| 
| 
| _______________________________________________
| ghc-devs mailing list
| ghc-devs at haskell.org
| http://www.haskell.org/mailman/listinfo/ghc-devs