Why do we put GMP allocations on GHC heaps?

[Gergely Risko]

Dear GHC gurus,

I've been looking into how GHC uses GMP (with the hidden agenda of
taking the work of replacing it with something that is BSD license
compatible and so can be linked in and shipped statically by default).

I think I more or less understand how GMP memory is managed and how the
GC works together with it.  Actually understanding the "how" was not
that hard, everything is quite clearly commented.

What I couldn't find any reference for is the "why".  Why does GHC do
this?  Would it be possible to just not do this and let GMP malloc and
free for itself (obviously we would have to call mpz_free here and
there, but that seems doable).

I have multiple ideas, but don't know which one (if any) is correct:
  - performance reasons,
  - memory defragmentation reasons,
  - GHC GC moves around stuff and that would somehow break,
  - the previous one + threads + race conditions.

Second question: let's assume for a moment that we don't have any
licensing issues with a GMP like library, can be linked statically into
GHC, but we decide to go with the same allocation methodology as with
GMP.  Am I right when I think that linking statically solves the
technical issues too.

More concretely: openssl BN uses the openssl_malloc function can only be
overridden openssl wide.  But if we link statically, than this override
won't affect external openssl library bindings, because the openssl
symbols in our object files won't even be exported, right?

Third question: is replacing with openssl bn an acceptable path to
you guys?  I saw that 6 years ago there were work on getting
integer-simple performance wise good enough to be the default and then
adding other bignum libraries externally, but none of this happened.
I see how sexy project it is computer science wise to write a bignum
library in Haskell, but will we really do it?

Thanks,
Gergely
(errge)