[GAP] Effect of using malloc for temporary allocations in GAP
dmitrii.pasechnik at cs.ox.ac.uk
Tue Jan 3 13:20:58 GMT 2017
On Tue, Jan 03, 2017 at 10:36:08AM +0000, Christopher Jefferson wrote:
> 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.
Aren't also the heap and a virtual memory region obtained by
mmap separate even within a process?
> 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).
Why would GASMAN be problematic with multithreading? Surely, it will
need a mechanism to pause all the other threads while collecting
garbage, but apart from this, is there anything fundamental that
makes it hard to port?
> 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