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

Christopher Jefferson caj21 at st-andrews.ac.uk
Tue Jan 3 10:36:08 GMT 2017

A couple of points (replying in my phone, sorry for bad formatting).

The use of things like sbrk is I believe just because this code is old, and originated before you could rely on a good mmap and friends.

Other processes shouldn't be a problem -- all modern OSes give every process a separate memory space. It could obviously be a problem for things like sage, which want to load into the same process as gap.

With regards GASMAN. It is very fast, and I believe any replacement would be much slower. One of the biggest problems with HPC gap is that boehm is much slower.

Of course gasman has issues -- it can't support multithreading (hence can't be in hpcgap), is moving, requires continuous address space. But any replacement will, for gap's current usage, be I believe slower. Also much of gaps internals relies on features of gasman other allocators may not provide (like cheap access to the exact size of any allocation for example).

I would be tempted to mostly leave gasman as is. The only issue I know of is removed in 64bit, and in 32bit it isn't proving too serious -- several libraries like semigroups++ and ferret at mallocing all the time and working fine.

We should make a careful effort to clean up a little (maybe dump sbrk code, make sure we set up memory space well in 32bit), then bless mallocing, and tell anyone with address space issues to switch to a 64bit GAP.

From: Dmitrii Pasechnik
Sent: Monday, 2 January, 22:10
Subject: Re: [GAP] Effect of using malloc for temporary allocations in GAP
To: Max Horn
Cc: gap at gap-system.org
> > In any case, this all is completely besides the point of my original question. IMHO it's still quite relevant: we seem to have established that the system mallocs happen in another VM region, and so they interfere with GASMAN no more than other, outside of our control, processes. Fixing GASMAN so that it can use non-continuous address space seems to the the only real way out.

More information about the Gap mailing list