__gmp_allocate_func and garbage collection

[Marc Glisse]

On Tue, 5 May 2009, Torbjorn Granlund wrote:

> Are you saying that a struct that contains a pointer is the rub?  So,
> any time we malloc an mpz_t (not just declare it) these garbage
> collectors will become unhappy?

Yes (well they are happy if you use the regular malloc replacement, just 
not if you use the raw use-at-your-own-risks fast malloc_atomic). At least 
I think so, I don't have much experience at all using garbage collectors. 
My understanding is that you would GC_malloc the mpz_t, GC_malloc_atomic 
the _mp_d, and the GC would see that the second block of memory is 
referenced in the first block, but would not bother looking through the 
second block to see if it references anything else.

> I really don't know where this happens in GMP, but it should be quite
> rare.

Indeed, as I said I only found an occurence in the random generator code 
(excepting debugging, tuning and testing code). Which is why it looked to 
me like it could make sense to try and provide (and document) guarantees 
on malloced data not containing pointers to malloced data.

I don't know if it is easy to remove the few problematic uses, or if that 
would require introducing an extra allocation function. I am also missing 
data to quantify the potential speed improvements by using 
GC_malloc_atomic instead of the safe GC_malloc.

-- 
Marc Glisse