Re: memory management

[Ilya Zakharevich <ilya@Math.Berkeley.EDU>]

On Mon, Jun 16, 2003 at 10:56:47PM +0200, Bill Allombert wrote:
> 2) We use malloc(3) to allocate the PARI stack on the heap. In fact 
> we do not have much choice, since PARI/GP is a library. Allocating
> memory without malloc would forbid programs linked with libpari to use
> malloc() which is not acceptable. This would be a real pain for GP
> already.

I do not know what over ways of memory allocation do you mean here.
It is either malloc()/sbrk(), or memory-map.  Both do not allow a
growth, AFAIK.

> 3) malloc(3) does not permit to extend a memory block in place,
> which is what is required to expend the PARI stack.

AFAIU, there is no need to grow a block to extend the PARI stack.
When needed, just allocate a new region of larger size, *keep the old
stuff* on the old region (keeping the boundaries of the old stack on
the "stack of stacks"), and fix gerepile() so that it allows chunks
"crossing the boundary" between the old and the new stack (in such
situations the repile should happen via the heap).

Hmm, I need to think about this more - if a function does not use
gerepile(), this may break things; maybe some more wizardry will help.

> 3) The main drawback of the stack is that garbage collecting change addresses
> of object in the stack. To work-around this problem, we use clone which are
> temporary copy of GEN in the heap that we free later. This may make
> stack management easier in hard case.

IMO, the main drawback of the PARI stack model is that the data is
constantly shuffled in memory.  If a function call tree is deep (e.g.,
your data type tree is deep), the data is memmov()ed many many times.
BTW, the same holds for the heap allocation - since the heap objects
are not refcounted, one cannot be just "referenced" from another - it
needs to be copied there.  [The last part is easy to fix with t_EXT,
though.]

> 2) The bad: mmap(2)ing /dev/zero with MAP_FIXED to allocate the stack 
> at some specified address, so that we can reallocate it at the same 
> place. This look clever, but not only it is not portable but also
> MAP_FIXED is not waranted to work at all.

I do not see how this may be beneficial at all (unless on the - few -
systems without memory overcommitment).  You need to mark the memory
below this region as "do not use".  Why not mmap() then the whole
region (including the "do not use part") at the start?  And why not
malloc() the corresponding chunk of memory instead (assuming
overcommitment, so that large malloc() has the same overhead as the
small one).

Hope this helps,
Ilya