[GAP] Effect of using malloc for temporary allocations in GAP

Dmitrii Pasechnik dmitrii.pasechnik at cs.ox.ac.uk
Mon Jan 2 14:01:20 GMT 2017


Dear all,
On Mon, Jan 02, 2017 at 01:45:33PM +0100, Max Horn wrote:
> I would like to double-check what the status of using malloc/free in GAP for allocations is. So far I operated under the following assumptions, based on how I recall past discussions on this:
> 
> (1) on 32 bit systems, using malloc/free can interfere negatively with the GC, as a malloc'ed region of memory can prevent the GC from growing its heap.
> (2) on 64 bit systems, this is also the case, but the chance for this is much, much lower (due to the larger address space), and hence it is mostly safe to use malloc/free -- but this is only a heuristic, in practice you could be unlucky and still end up with a GAP crashing because it cannot extend its heap anymore, despite there being plenty of free RAM.
> 
> Next, I was wondering about *temporary* allocations... Is the following true or false?
> 
> (3)  It is OK to malloc some space, as long as you free it before the GC runs next (resp. before the GC tries to grow its heap)
> 
> 
> It would be nice if this could be either confirmed or refuted by those who know our GC well enough, and also the memory managers .
> 
> 
> Grepping through the GAP kernel reveals that  GAP_rl_func sometimes mallocs some temporary space. So I am inclined to think (3) holds, but would like to know for sure.
> (I also note some malloc() calls in InitSystem() from system.c, but those are only executed if SyAllocPool==0, which can only happen on CYGWIN32).
> 
> The reason why I am asking is because I've been recently looking into our GMP interface, and I noticed two things:
> 
> (a) We are using the low-level GMP interfaces, but these can in fact also make temporary allocations -- e.g. mpn_gcd may do so. So I guess this is another data points towards (3) being true.
> 
> (b) If (3) is true, then we could use the mpz_* APIs, too -- while this would require us to perform some copying around, I am pretty sure that we would still see a noticeable net-benefit for computing things like factorials, binomials, roots, PowerModInt, various number theoretical stuff (see <https://gmplib.org/manual/Number-Theoretic-Functions.html>) etc.
> It is quite tempting to just try this, but it only makes sense if it does not cause issues down the road.

I would like to point out that GMP allows one to specify her/his own
memory allocator: https://gmplib.org/manual/Custom-Allocation.html
(I'm surprised that GAP does not use it, or does it?)

This is what PARI and Macaulay2 do, IIRC.
Ideally, GAP ought to use this feature, too.
Then at least in regard of GMP there would be no mallocs to worry about.


Just in case,
Dima



More information about the Gap mailing list