Why do we put GMP allocations on GHC heaps?

[Edward Kmett]

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> 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
> 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/1a94f834/attachment.html>