__gmp_allocate_func and garbage collection
marc.glisse at normalesup.org
Fri Jun 5 09:49:16 CEST 2009
[quoting the whole message for context, since this is not so recent]
On Tue, 5 May 2009, Marc Glisse wrote:
> 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.
I said I was missing data, so let me add it here for completeness:
I tried this with 2 real programs (not artificial testcases) from the
CGAL library, and got a speed-up between 5 and 10%. While I was there I
also noticed a 2x slowdown replacing the libc malloc by the jemalloc that
comes with firefox-3.0, and a speed-up between 2 and 20% using the lazy
allocation scheme mentionned in the tasks file.
PS: the order of the arguments of __gmp_reallocate_func is a pain :-(
More information about the gmp-discuss