|Bill Allombert on Thu, 26 Jun 2003 16:18:10 +0200|
[Date Prev] [Date Next] [Thread Prev] [Thread Next] [Date Index] [Thread Index]
|Re: memory management|
On Tue, Jun 17, 2003 at 03:57:59AM -0700, Ilya Zakharevich wrote: > 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. You can use sbrk() directly. If you use a single sbrk()ed memory bloc you can grow it. GAP use that, AFAIK. Of course, this forbid the use of malloc() in the code. > 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.] I agree that something that having one stack per functions could be better performance wise. Something like obstack could help. Cheers, Bill.