Why do we put GMP allocations on GHC heaps?

[Gergely Risko]

On Tue, 22 Oct 2013 16:36:45 -0700, "Edward Z. Yang" <ezyang at MIT.EDU> writes:

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

Yes, I was thinking of this alternative strategy.

I can understand that this may be slower in CPU, but can you please
elaborate why would it be worse in memory, how the frees wouldn't happen
in a "timely manner"?  I thought finalisers are called when the
referencee is GCd, so if we free the mpz in the callback, then where are
we going wrong?

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

So we certainly don't want to replace the impossibility of wrapping
libgmp in a hackage library with the impossibility of linking openssl :)

Thanks for the input, if I go BN, I'll prioritize this to one of the
first issues I tackle, because everyone is telling me that this is hard
and I want to fail fast.

Gergely