[GAP] Effect of using malloc for temporary allocations in GAP
dmitrii.pasechnik at cs.ox.ac.uk
Mon Jan 2 18:31:46 GMT 2017
On Mon, Jan 02, 2017 at 06:24:15PM +0100, Max Horn wrote:
> > On 02 Jan 2017, at 17:18, Dmitrii Pasechnik <Dmitrii.Pasechnik at cs.ox.ac.uk> wrote:
> > On Mon, Jan 02, 2017 at 03:07:34PM +0100, Max Horn wrote:
> >>> On 02 Jan 2017, at 15:01, Dmitrii Pasechnik <Dmitrii.Pasechnik at cs.ox.ac.uk> wrote:
> >>> 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?)
> >> GAP cannot use these hooks, because the GAP GC is a moving GC.
> > Well, these hooks allow one to bundle on a custom malloc with address space
> > protected from GC.
> The issue is not protecting the address space from our GC. It is more about
> the reverse, i.e. "protecting" our GC from an allocation in a place that
> prevents the GASMAN heap from growing.
Why does GASMAN use the heap (managed by (s)brk/malloc) as opposed to a separate virtual memory
region which one can obtain using mmap?
Or am I missing something?
> > There is probably quite a big choice of custom
> > mallocs to pick, and very small, or none, changes to the GC needed...
> "Probably"? That's a bold statement to make -- I am not aware of any (unless
> you count replacing GASMAN by Boehm GC, which technically is a "custom
> malloc"). And I have a hard time even imagining a way how a 3rd party
> allocator, which is not aware of GASMAN, would pull that off without major
> changes to GASMAN and/or that allocator. (unless that custom allocator did
> something serious heavy lifting including stack and register walks etc, like
> Boehm GC).
no, I meant a "classical" malloc/free, with explicit
free(), run in a dedicated VM region. Again, if this would work, then
it might be easier instead to make GASMAN use such a region, and then
the heap can be used for the normal brk/malloc operations.
I peeked a bit into Macalay2 code---it uses Boehm GC.
(And debugging is unpleasant, to say the least.)
They still have to patch a lot of external libraries they use, as
it's not always the case that they are compatible with Boehm GC.
E.g. they patch FLINT http://www.flintlib.org/
as by default it mangles pointers too badly (and pay a slight
performance penalty in FLINT already).
More information about the Gap