Why do we put GMP allocations on GHC heaps?

Gergely Risko gergely at risko.hu
Wed Oct 23 15:44:15 UTC 2013

On Wed, 23 Oct 2013 10:07:27 -0400, Edward Kmett <ekmett at gmail.com> writes:

> Before that Dan Peebles took a stab at rehooking the GMP allocator
> hook for me to introspect on the stack and switch to malloc when
> called from the constant cache, so we could just link to the host MPFR
> implementation. That _worked_, but the code was awful, and it wouldn't

Wait, this sounds like a big hack, but isn't this a quite good interim
solution to this whole issue?  Not to the licensing, but to the

The functions in ./libraries/integer-gmp/cbits/alloc.c could just read
some thread-local global variable to know whether they're being called
"from GHC Integer", and GHC would write to this before calling the GMP
functions.  Or instead of a TL global variable, mark the stack somehow.

This sounds hackish, but not so bad in my opinion.  The GHC+GMP
integration is already hacky memory management wise.

Also, the current situation is kind of a deadlock:
  - we should write integer-gmp packages to test their performance,
  - but they would only work with a special GHC compiled with
  - when we have a perfect one, we can remove integer-gmp from GHC
    itself, so they work.

It's hard to develop and test a library with any reasonable number of
test subjects if it needs a special GHC...


More information about the ghc-devs mailing list