Why do we put GMP allocations on GHC heaps?

[Carter Schonwald]

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
dropping Gmp

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
be justifiable.

 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.
>
>
> On Tue, Oct 22, 2013 at 7:36 PM, Edward Z. Yang <ezyang at mit.edu<javascript:_e({}, 'cvml', 'ezyang at mit.edu');>
> > 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
>> to
>> work the way you want it to.
>>
>> Cheers,
>> Edward
>> _______________________________________________
>> ghc-devs mailing list
>> ghc-devs at haskell.org <javascript:_e({}, 'cvml', 'ghc-devs at haskell.org');>
>> http://www.haskell.org/mailman/listinfo/ghc-devs
>>
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://www.haskell.org/pipermail/ghc-devs/attachments/20131022/371fdc97/attachment-0001.html>