Re: "kill" and deallocating memory in GP.

[Karim BELABAS <Karim.Belabas@math.u-psud.fr>]

Matias Atria <matria@abello.dic.uchile.cl> wrote:
> I've found that the 'kill' function is almost unusable in recent versions
> of PARI. After using it a couple of times I get a segment violation
> forcing me to restart GP and loosing all the computations I've done
> before. Is this a well known problem? Is there a fix? I can provide more
> information about the situation if necessary.

I definitely would like more information (a minimal script that exhibits
the bug for instance).

> Also, one of the reasons I use 'kill' so much is to make GP free some
> memory. I have to compute matrices with several thousand entries and dump
> them imediately to a file, so I don't need them to be held in memory for
> too long (and I can't allocate too many megs for the PARI stack). Is
> there a cleaner way of doing this? I'm not even sure the 'kill' function
> deallocates any memory from the stack. Can one of the PARI gurus please
> enlighten me?

Picture it this way: the "stack" is the scratchboard used by all library
functions for their computations. The "heap" (disjoint from the stack) is
the permanent storage: history entries (%1, %2, ...), variable values,
clones , some constants (0, 1, ...).                  ^^^^^^^^^^^^^^^ 

kill destroys a variable value (and the variable itself), so does not
affect the stack in any way. Your stack overflows for some other reasons.
The heap grows very slowly and, unless you install() some badly written
custom modules (creating a lot of clones for instance), should not be a
problem (you can also lower histsize if your intermediate results are
huge).

Stack is emptied each time a new prompt is printed, but actually grows
during the execution of a script line. You might try to add some 
print(getheap) statements within you script, and set memory debug level to
at least 2 (type \gm 2). You get much more information is you use the
debugging version produced after a Configure -g, but you might already see
something.

Hope this helps,

  Karim.

P.S: kill is meant to remove an annoying symbol from the hashtables (see
user's manual): say

(18:40) gp > f=1
%1 = 1
(18:40) gp > f()=
  ***   unused characters: f()=
                            ^--
(f is remembered as a variable: impossible to use it as a function name)
(18:40) gp > kill(f)
(18:41) gp > f()= \\ ok now !

If you think the value of f take too much room, just type e.g f = 0. This
will destroy the old value and replace it with something small.

Note: each time f is given as a parameter for a user's function, a copy
is made, which is not destroyed by f = 0 as above (that's PARI's idea of
local variables). As a rule one should avoid passing huge objects as
parameters. Use global variables for that...

Besides, killing a variable has the annoying side effect of permanently
removing a variable number (from a list of MAXVARN = 16383 entries on
32-bit systems):

(18:42) gp > while(1,kill(y))
  ***   no more variables available: while(1,kill(y))
                                             ^-------
(after one or two seconds).
(18:43) gp > length(reorder)
%2 = 16382
(that many variables have been used...)

This behaviour is the simplest solution to the following problem: how do we
handle objects using a killed variable

Note 2: "x" is a special case: it's the only variable that is created upon
startup, and is never actually killed: while (1, kill(x)) initiates an
infinite loop.
--
Karim Belabas                    email: Karim.Belabas@math.u-psud.fr
Dep. de Mathematiques, Bat. 425
Universite Paris-Sud             Tel: (33 1) 01 69 15 57 48
F-91405 Orsay (France)           Fax: (33 1) 01 69 15 60 19
--
PARI/GP Home Page: http://pari.home.ml.org