Why do we put GMP allocations on GHC heaps?
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