On Tue, 22 Oct 2013 16:36:45 -0700, "Edward Z. Yang"
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