Why do we put GMP allocations on GHC heaps?
carter.schonwald at gmail.com
Wed Oct 23 01:29:48 UTC 2013
At some point I'd actually like to explore trying to build a satisfactory
"integer-fancy" in Haskell, but there's a few technical challenges I'll be
trying to do first before there'll be an engineering story for building a
satisfactory Haskell replacement that is performant enough to justify
Basically I think until we can build an alternative with competitive
performance in straight ghc Haskell, there's no good argument for dropping
Gmp overall. There are a number of great reasons that everyone has
mentioned, but it needs to be a net win for everyone before the leap could
If I manage to get my target work for 7.10 sorted out with a few months to
spare, I may try to spend a few months exploring this, though no promises.
Current ghc doesn't have the right primops to do this yet.
On Tuesday, October 22, 2013, Edward Kmett wrote:
> Not suggesting we actually switch, but there is one strong 'why': You
> can't link Haskell code with any library that uses GMP internally
> internally without switching to using integer-simple. I've been trying with
> very limited success to get good MPFR bindings for Haskell for ~3 years now
> as a result.
> The most likely fix actually involves changes to MPFR as their constant
> cache and our garbage collector don't play nice.
> > wrote:
>> Hey Gergeley,
>> > (obviously we would have to call mpz_free here and there, but that
>> > seems doable).
>> Actually, this is precisely the problem. When is a GMP integer freed?
>> It can have pointers to it from objects on the heap, so this free should
>> only occur when the integer is dead, with no references from the heap.
>> How can that be arranged? Well, the garbage collector is responsible
>> for figuring this out. So why shouldn't they just live on the heap, and
>> then smoothly integrate with the existing garbage collector.
>> The alternate strategy is to arrange that some sort of "callback" gets
>> invoked when an object dies. You can achieve this using our finalizer
>> support, but you pay an efficiency penalty and cannot guarantee that
>> the integers will get freed in a timely manner at all.
>> > 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?
>> Only if literally two copies of OpenSSL are linked. This seems unlikely
>> work the way you want it to.
>> ghc-devs mailing list
-------------- next part --------------
An HTML attachment was scrubbed...
More information about the ghc-devs