__gmp_allocate_func and garbage collection

[Marc Glisse]

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

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.

-- 
Marc Glisse

PS: the order of the arguments of __gmp_reallocate_func is a pain :-(