__gmp_allocate_func and garbage collection
marc.glisse at normalesup.org
Tue May 5 23:35:37 CEST 2009
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
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.
More information about the gmp-discuss