Hi there all!
I have yet another question to test you with.
Here goes:
(setq hello 10)
now "hello" takes up space in memory, how do I deallocate it??
Thanks,
Later,
LARS - ····@qucis.queensu.ca
In article <······················@qucis.queensu.ca>, ····@qucis.queensu.ca (Larry Singleton) writes:
|> Hi there all!
|>
|> I have yet another question to test you with.
|>
|> Here goes:
|>
|> (setq hello 10)
|>
|> now "hello" takes up space in memory, how do I deallocate it??
|>
|> Thanks,
|>
|> Later,
|>
|> LARS - ····@qucis.queensu.ca
The short answer is "you don't", but if you really feel compelled to
eliminate a symbol, read the documentation for unintern. In general,
removing a symbol is something you probably do not want to do--it
saves very little space (see below) and can cause a lot of grief.
However, you might really be asking a related question, so read on,
starting with a little background...
Note that if you enter something like
'hello
a symbol named "HELLO" is created and recorded in the current
package, and (depending on the lisp implementation) a memory
location is probably (in fact, almost certainly) allocated to store
the pointer for the value of that symbol. Other cells for pointers
to the property list, function cell, etc. are also probably allocated
at this time. If you include the space used to record the symbol in
the package, a reasonable estimate is that space for about 6 to 8
pointers (e.g. 24 to 32 bytes) is consumed, plus enough memory to
store the namestring "HELLO" (8 or 12 bytes?). These numbers can
vary among implemenations, since space for hash codes and other
things might also be allocated at this time. In general, if your
machine has megabytes of memory, you will need to have hundreds
or thousands of symbols before the space they use becomes worth
worrying about. (Note that if you enter 'hello again, no new storage
is allocated--instead a pointer at the pre-existing symbol is returned.)
Now entering
(setq hello 10)
will probably allocate no additional space, since the value 10 is
probably a fixnum and can be stored directly in the slot that would
otherwise hold a pointer.
On the other hand (and this might be the question you meant to ask),
(setq hello (cons 1 2))
will allocate a new cons cell and put a pointer to it in the value slot
for the symbol named "HELLO". You can reclaim the cons cell simply
by replacing that pointer with a pointer at something else, e.g.
(setq hello nil)
If the value cell for hello held the only pointer to that cons cell, the
cons cell will be reclaimed automagically by the garbage collector--
you don't need to think about it. If someone else also had a pointer
at it, e.g. you did (setq goodbye hello) before doing (setq hello nil),
then the garbage collector will not reclaim the cons cell until that
other pointer is also released. All of this is completely automatic
and you normally do not need to think about it unless you are
worried about performance issues.
Btw, that is what happens with the forms you enter to be evaluated.
The interpreter keeps them for a while and when it is done it simply
lets go of them, and the next garbage collection reclaims the space
they used.
--
James McDonald
Kestrel Institute ········@kestrel.edu
3260 Hillview Ave. (415) 493-6871 ext. 339
Palo Alto, CA 94304 fax: (415) 424-1807
--
James McDonald
Kestrel Institute ········@kestrel.edu
3260 Hillview Ave. (415) 493-6871 ext. 339
Palo Alto, CA 94304 fax: (415) 424-1807
In article <····················@kestrel.edu>, ········@kestrel.edu (Jim McDonald) writes:
[was responding to a question about how to deallocate symbols,
excerpt. ]
|> The short answer is "you don't", but if you really feel compelled to
|> eliminate a symbol, read the documentation for unintern. In general,
|> removing a symbol is something you probably do not want to do--it
|> saves very little space (see below) and can cause a lot of grief.
|>
|> However, you might really be asking a related question, so read on,
|> starting with a little background...
|>
|> Note that if you enter something like
|>
|> 'hello
|>
|> a symbol named "HELLO" is created and recorded in the current
|> package, and (depending on the lisp implementation) a memory
|> location is probably (in fact, almost certainly) allocated to store
|> the pointer for the value of that symbol. Other cells for pointers
|> to the property list, function cell, etc. are also probably allocated
|> at this time. If you include the space used to record the symbol in
|> the package, a reasonable estimate is that space for about 6 to 8
|> pointers (e.g. 24 to 32 bytes) is consumed, plus enough memory to
|> store the namestring "HELLO" (8 or 12 bytes?). These numbers can
|> vary among implemenations, since space for hash codes and other
|> things might also be allocated at this time. In general, if your
|> machine has megabytes of memory, you will need to have hundreds
|> or thousands of symbols before the space they use becomes worth
|> worrying about. (Note that if you enter 'hello again, no new storage
|> is allocated--instead a pointer at the pre-existing symbol is returned.)
How does something like a lisp machine deal with this problem? If I
had a lisp machine running some sort of common lisp, wouldn't I have
to either add code to figure out what symbols could be garbage collected,
or else reboot the machine every once in a while when the symbols started
to eat up the memory?
mike
In article <·····················@hellgate.utah.edu>, ·····························@cs.utah.edu (Michael Callahan) writes:
[my earlier post elided]
|> How does something like a lisp machine deal with this problem? If I
|> had a lisp machine running some sort of common lisp, wouldn't I have
|> to either add code to figure out what symbols could be garbage collected,
|> or else reboot the machine every once in a while when the symbols started
|> to eat up the memory?
|>
|> mike
This is probably less of a problem than you might think.
There are two kinds of symbols -- those that are interned and those that are
not (a.k.a. gensyms). Interned symbols do "silt up" in memory as you indicate,
but very slowly with respect to the memory available. Even 100,000 symbols isn't
necessarily a major problem (say they use 5 Mbyte out of a 60 Mbyte image), and
think how long it would take to produce that many distinctly named symbols!
Hardware failures and/or boredom with or completion of the current session
probably will occur first.
Note that multiple occurrences of the same symbol only consume the space
need for the extra pointers to the symbol. These are presumably within lists,
etc. which are collected efficiently when they become inacessible. You could
write code to mechanically generate copious interned symbols, but the
motivation for such action is obscure (here is the gun, there is your foot...).
A more plausible way to get the problem you envision would be to use the
normal lisp reader to process hundreds of thousands of pages of non-repetitive
symbolic data (say, back issues of a journal, or whatever). In that case you
might really intern enough symbols to get into trouble. (And you would be
well advised to write your own little reader for that data!)
In situations where you do want lots of temporary symbols, gensym can be used
to generate a new symbol that is not interned, hence the space for that gensym
will be collected when there are no more pointers at it. A program that
generated millions or even billions of gensyms, each used for a short time,
would be at least a little suspect, but should run indefinitely.
Note that debugging or otherwise interacting with data that contains gensyms
can be a bit tedious, because you can't refer to such symbols by name, but must
chase pointers to get to them (or have the printer make them mouse-sensitive).
They also have informative names like G1264, and multiple gensyms can have
the same name, since the system doesn't uses their name to access them.
Btw, it is probably a bad idea to "add code to figure out what symbols could be
garbage collected", even if they are silting up. In a situation like that, it would
be far better to figure out how to avoid creating such (ultimately) superfluous
symbols in the first place.
--
James McDonald
Kestrel Institute ········@kestrel.edu
3260 Hillview Ave. (415) 493-6871 ext. 339
Palo Alto, CA 94304 fax: (415) 424-1807
--
James McDonald
Kestrel Institute ········@kestrel.edu
3260 Hillview Ave. (415) 493-6871 ext. 339
Palo Alto, CA 94304 fax: (415) 424-1807
In article <····················@kestrel.edu> ········@kestrel.edu
(Jim McDonald) writes:
A more plausible way to get the problem you envision would be to
use the normal lisp reader to process hundreds of thousands of
pages of non-repetitive symbolic data (say, back issues of a
journal, or whatever). In that case you might really intern enough
symbols to get into trouble. (And you would be well advised to
write your own little reader for that data!)
this is a bit off subject, but using symbols instead of strings to
contain words generally leads to problems. using the read to read
natural language leads to even more problems.
if you *do* happen to try using symbols to represent words, then you
would be very well advised to keep them in a separate package.
In article <················@lole.crl.nmsu.edu>, ···@crl.nmsu.edu (Ted Dunning) writes:
|>
|>
|> In article <····················@kestrel.edu> ········@kestrel.edu
|> (Jim McDonald) writes:
|>
|>
|> A more plausible way to get the problem you envision would be to
|> use the normal lisp reader to process hundreds of thousands of
|> pages of non-repetitive symbolic data (say, back issues of a
|> journal, or whatever). In that case you might really intern enough
|> symbols to get into trouble. (And you would be well advised to
|> write your own little reader for that data!)
|>
|>
|> this is a bit off subject, but using symbols instead of strings to
|> contain words generally leads to problems. using the read to read
|> natural language leads to even more problems.
|>
|> if you *do* happen to try using symbols to represent words, then you
|> would be very well advised to keep them in a separate package.
Why would that help solve the space problem? They would still take up
the extra space.
mike
In article <····················@kestrel.edu>, ········@kestrel.edu (Jim McDonald) writes:
|>
|> In article <·····················@hellgate.utah.edu>, ·····························@cs.utah.edu (Michael Callahan) writes:
|>
|> [my earlier post elided]
|>
|> |> How does something like a lisp machine deal with this problem? If I
|> |> had a lisp machine running some sort of common lisp, wouldn't I have
|> |> to either add code to figure out what symbols could be garbage collected,
|> |> or else reboot the machine every once in a while when the symbols started
|> |> to eat up the memory?
|> |>
|> |> mike
|>
|> This is probably less of a problem than you might think.
|>
|> There are two kinds of symbols -- those that are interned and those that are
|> not (a.k.a. gensyms). Interned symbols do "silt up" in memory as you indicate,
|> but very slowly with respect to the memory available. Even 100,000 symbols isn't
|> necessarily a major problem (say they use 5 Mbyte out of a 60 Mbyte image), and
|> think how long it would take to produce that many distinctly named symbols!
|> Hardware failures and/or boredom with or completion of the current session
|> probably will occur first.
On one of our file servers right now, 'ps -aux | wc -l' showed 112 lines.
That's 111 proccesses, and the title line for ps. It would seem to me that
if I were to try to run that many programs on a lisp machine, then the
symbols from all of the different packages would start to pile up. Not to
mention the packages themselves that would all be floating around.
|> Note that multiple occurrences of the same symbol only consume the space
|> need for the extra pointers to the symbol. These are presumably within lists,
|> etc. which are collected efficiently when they become inacessible. You could
|> write code to mechanically generate copious interned symbols, but the
|> motivation for such action is obscure (here is the gun, there is your foot...).
|>
|> A more plausible way to get the problem you envision would be to use the
|> normal lisp reader to process hundreds of thousands of pages of non-repetitive
|> symbolic data (say, back issues of a journal, or whatever). In that case you
|> might really intern enough symbols to get into trouble. (And you would be
|> well advised to write your own little reader for that data!)
This is something else that had occured to me. Proccessing large amounts of
text in some way or another would seem to create a large number of seldom-used
symbols. It would be nice if I didn't have to write my own read, hash tables
full of gensyms, or whatever mechanism I was going to use. It would also be
nice if I could have it all cleaned up for me when I finished with that
particular proccess, withought having to reboot.
|> In situations where you do want lots of temporary symbols, gensym can be used
|> to generate a new symbol that is not interned, hence the space for that gensym
|> will be collected when there are no more pointers at it. A program that
|> generated millions or even billions of gensyms, each used for a short time,
|> would be at least a little suspect, but should run indefinitely.
|>
|> Note that debugging or otherwise interacting with data that contains gensyms
|> can be a bit tedious, because you can't refer to such symbols by name, but must
|> chase pointers to get to them (or have the printer make them mouse-sensitive).
|> They also have informative names like G1264, and multiple gensyms can have
|> the same name, since the system doesn't uses their name to access them.
|>
|> Btw, it is probably a bad idea to "add code to figure out what symbols could be
|> garbage collected", even if they are silting up. In a situation like that, it would
|> be far better to figure out how to avoid creating such (ultimately) superfluous
|> symbols in the first place.
|>
|> --
|>
|> James McDonald
|> Kestrel Institute ········@kestrel.edu
|> 3260 Hillview Ave. (415) 493-6871 ext. 339
|> Palo Alto, CA 94304 fax: (415) 424-1807
|> --
|> James McDonald
|> Kestrel Institute ········@kestrel.edu
|> 3260 Hillview Ave. (415) 493-6871 ext. 339
|> Palo Alto, CA 94304 fax: (415) 424-1807
mike
In article<·····················@hellgate.utah.edu>·····························@cs.utah.edu (Michael Callahan) writes:
>
> On one of our file servers right now, 'ps -aux | wc -l' showed 112 lines.
> That's 111 proccesses, and the title line for ps. It would seem to me that
> if I were to try to run that many programs on a lisp machine, then the
> symbols from all of the different packages would start to pile up. Not to
> mention the packages themselves that would all be floating around.
Not really. On my Lisp Machine:
Lox:> (let ((x 0)) (process:map-over-all-processes #'(lambda (y) (incf x))) x)
75
Lox:> (chaos:uptime)
Host Name Time up
LOX 3 weeks 1 day 17 hours 31 minutes 35 seconds
And I don't have dynamic garbage collection turned on, only ephemeral.
Stephen P. Smith
······@Lox.Intel.COM
Disclaimer: There is very little Intel Inside this post.
Ok ok, looks like it's only a very minor problem then. I suppose if
memory goes away that slowly, then it's probably not something that
should have alot of time devoted to it. I was just considering what
a multi-user lisp environment would be like, and it seemed to me that
if you had bunches of people writing and using code at the same time,
then this maight become somewhat of a problem.
mike
Actually it seems to me that the parallel is not appropriate anyway.
Lisp Machines were conceived as (extremely expensive - yes) "Personal
Computing Devices". The trend toward PC's and Workstations proved that
at least the concept was right.
I am working with a Sparc1 on my desk and do only file I/O on the
server through the network.
Have a nice day
--
Marco Antoniotti
-------------------------------------------------------------------------------
Robotics Lab | room: 1219 - tel. #: (212) 998 3370
Courant Institute NYU | e-mail: ·······@cs.nyu.edu
...e` la semplicita` che e` difficile a farsi.
...it is simplicity that is difficult to make.
B. Brecht
In article <······················@qucis.queensu.ca>, ····@qucis.queensu.ca (Larry Singleton) writes:
> (setq hello 10)
> now "hello" takes up space in memory, how do I deallocate it??
If you had said,
(setf hello '(1 2 3 4))
then you could have deallocated the memory used by the list by doing
(setf hello nil)
but since '10' has negligible storage requirements compared to the
symbol structure itself, i presume you are asking how to get rid of
the symbol. Generally, there is little need to do this, but if you
*must* know, in Common Lisp you can type
(unintern 'hello)
to remove it.
rodrigo vanegas
··@cs.brown.edu
From: Bill Birch
Subject: Re: Need help to deallocate variables
Date:
Message-ID: <bxb.746964528@smurf>
In <················@vegas.cs.brown.edu> ··@cs.brown.edu (rodrigo vanegas) writes:
>In article <······················@qucis.queensu.ca>, ····@qucis.queensu.ca (Larry Singleton) writes:
>> (setq hello 10)
>> now "hello" takes up space in memory, how do I deallocate it??
[stuff deleted]
Just for fun, here is a RefLisp session that may help explain this.
RefLisp prints out the number of currently used cells in the prompt.
(It collects all garbage ASAP) So a prompt "1890> " means there
are 1890 cells in use. Here it is:
; reading /staff/bxb/lisp/reflisp/init.lsp
; reading common.lsp
It's just after five past eight .
3880> 'hello
hello
3885> (setq hello 10)
10
3886> (setq hello (cons 1 2))
(1 . 2)
3888> (setq hello nil)
nil
3885> (setq hello (oblist))
(write-char cos fu.
.
.
[stuff deleted]
.
.
floatp exit semctl olddef)
4198> (setq hello nil)
nil
3885>
From this you can see how much is used for each
value of 'hello, and that when you set it to
nil, you get some free memory back. (Which is
important, cos RefLisp is memory hungry! he he
he he he :-)
Bill
Hello,
while reading articles in different Lisp-news-groups, I heard about
CMULisp, RefLisp, elisp, Xlisp, AKCL, CLisp and some other free Lisp
implementations.
Did anybody compare these different implementations (with respect to
portability, CL-standard, efficience, etc.) ?
In our group we are using the commercial Lucid CL and a little XLisp,
tried a little CLisp and some CMU. Since we are looking for a free
Lisp implementation we are interested in any information about differences
between them:
Is there a best one, or can any of these free implementations be ruled
out, or does a ranking not make sense?
thanks in advance for any information,
benno