Why do we put GMP allocations on GHC heaps?

[Edward Kmett]

That actually would be a pretty reasonable way forward, that could maintain
the performance of the current approach without crippling GMP for other
consumers.

It'd probably be a fair bit of work, as you wind up up to your eyeballs in
the guts of the library, limbs everywhere, colorful body part metaphors
flying every which way.

It doesn't make accessing libraries like MPFR from Haskell in the most high
performance way all that much easier, but it does mean that if you linked
to a library that used them you wouldn't just start randomly segfaulting
like you do today.

If someone else doesn't get around to it first, I'll probably give it a
shot eventually.

-Edward


On Thu, Oct 31, 2013 at 3:39 AM, Florian Weimer <fw at deneb.enyo.de> wrote:

> * Edward Z. Yang:
>
> > 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 real problem here is that GHC uses the mpz_* functions and not the
> lower-level mpn_* functions, where the caller is responsible for
> memory management and which would play well with garbage collection
> (or any other memory management scheme).
> _______________________________________________
> 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/20131031/e259662b/attachment.html>