Hi
I'm fairly new to lisp and were wondering about the following:
When does a symbol stop to exist?
1 - Will a symbol be GC-ed when it is neither accessible from any package
nor being pointed to by any object (by object I mean the value, function,
etc. slot of any symbol, the car/cdr of a cons cell, etc.)?
Does this mean that the result of function make-symbol will be GC-ed if it
is not bound to some symbol, e.g.
> (make-symbol "TEST") ; 2 - the resulting symbol will
be GC-ed when the GC run (and *, ** and *** stops pointing to it).
> (symbol-value (make-symbol "TEST") 10) ; 3 - the resulting symbol will
be GC-ed as in 1 above even though it is bound to the value 10.
> (setf x (make-symbol "TEST")) ; 4 - symbol TEST will be GC-ed
when symbol X's value slot stops pointing to it.
Are the awnsers to 1, 2, 3 and 4 all yes?
Thanks.
Nico
"NicoD" <·······@netscape.net> writes:
> Are the awnsers to 1, 2, 3 and 4 all yes?
Basically yes, if in 3 you meant (setf (symbol-value ..) 10).
An object is reclaimed by GC when it can prove that there's no
(standard) way to get at a pointer to that object.
--
Frode Vatvedt Fjeld
+ Frode Vatvedt Fjeld <······@cs.uit.no>:
| An object is reclaimed by GC when it can prove that there's no
| (standard) way to get at a pointer to that object.
This is perhaps more correct if "is" is replaced by "may be".
More to the point, the OP should not worry about exactly when objected
are collected. Who cares if an inaccessible object is still present
somewhere in memory or not? If it's inaccessible, it's inaccessible,
and so for all practical purposes, it does not exist. GC is there to
make sure you do not run out of memory because of an accumulation of
inaccessible objects. The garbage collector is under no obligation to
collect objects as soon as they are inaccessible.
--
* Harald Hanche-Olsen <URL:http://www.math.ntnu.no/~hanche/>
- Debating gives most of us much more psychological satisfaction
than thinking does: but it deprives us of whatever chance there is
of getting closer to the truth. -- C.P. Snow
On Wed, 11 Aug 2004 22:02:43 +0200, Harald Hanche-Olsen wrote:
> + Frode Vatvedt Fjeld <······@cs.uit.no>:
>
> | An object is reclaimed by GC when it can prove that there's no |
> (standard) way to get at a pointer to that object.
>
> This is perhaps more correct if "is" is replaced by "may be".
I shure hope it will only be GCed if there's no way at all to access the
object later on :-/
> More to the point, the OP should not worry about exactly when objected
> are collected. Who cares if an inaccessible object is still present
> somewhere in memory or not? If it's inaccessible, it's inaccessible,
> and so for all practical purposes, it does not exist.
Well, in the case of symbols, things are a bit different. At some later
point the same symbol can "show up" (via read, eval, intern etc.). The
system has to garantee that the eq predicate holds. This _can_ be a
source of concern if your code generates a _lot_ of interned symbols.
Ralf Mattes
+ "R. Mattes" <··@mh-freiburg.de>:
| On Wed, 11 Aug 2004 22:02:43 +0200, Harald Hanche-Olsen wrote:
|
| > + Frode Vatvedt Fjeld <······@cs.uit.no>:
| >
| > | An object is reclaimed by GC when it can prove that there's no |
| > (standard) way to get at a pointer to that object.
| >
| > This is perhaps more correct if "is" is replaced by "may be".
|
| I shure hope it will only be GCed if there's no way at all to access
| the object later on :-/
Well, if you start messing around in memory, accessing objects behind
your Lisp's back, you deserve what you get.
| > More to the point, the OP should not worry about exactly when objected
| > are collected. Who cares if an inaccessible object is still present
| > somewhere in memory or not? If it's inaccessible, it's inaccessible,
| > and so for all practical purposes, it does not exist.
|
| Well, in the case of symbols, things are a bit different. At some later
| point the same symbol can "show up" (via read, eval, intern etc.). The
| system has to garantee that the eq predicate holds.
No. If CL-USER::FOO is GC-ed, it is because the symbol is no long
accessible. In particular, it is no longer interned in the CL-USER
package. (Or you have removed the CL-USER package.) If READ
encounters it again, it will intern a new symbol. Since there is no
old symbol to apply EQ to, your problem does not arise.
In fact, you don't even have to make the symbol go away. Just
unintern it:
CL-USER> (defvar *thing* 'foo)
*THING*
CL-USER> *thing*
FOO
CL-USER> (unintern 'foo)
T
CL-USER> *thing*
#:FOO
CL-USER> (eq *thing* 'foo)
NIL
So the old FOO and the new FOO are now different beasts, though they
have the same name and were both created as symbols in the CL-USER
package. (Note how the way the symbol prints changed after it was
uninterned.)
--
* Harald Hanche-Olsen <URL:http://www.math.ntnu.no/~hanche/>
- Debating gives most of us much more psychological satisfaction
than thinking does: but it deprives us of whatever chance there is
of getting closer to the truth. -- C.P. Snow
Harald Hanche-Olsen wrote:
>
> + "R. Mattes" <··@mh-freiburg.de>:
>
> | On Wed, 11 Aug 2004 22:02:43 +0200, Harald Hanche-Olsen wrote:
> |
> | > + Frode Vatvedt Fjeld <······@cs.uit.no>:
> | >
> | > | An object is reclaimed by GC when it can prove that there's no |
> | > (standard) way to get at a pointer to that object.
> | >
> | > This is perhaps more correct if "is" is replaced by "may be".
> |
> | I shure hope it will only be GCed if there's no way at all to access
> | the object later on :-/
>
> Well, if you start messing around in memory, accessing objects behind
> your Lisp's back, you deserve what you get.
>
> | > More to the point, the OP should not worry about exactly when objected
> | > are collected. Who cares if an inaccessible object is still present
> | > somewhere in memory or not? If it's inaccessible, it's inaccessible,
> | > and so for all practical purposes, it does not exist.
> |
> | Well, in the case of symbols, things are a bit different. At some later
> | point the same symbol can "show up" (via read, eval, intern etc.). The
> | system has to garantee that the eq predicate holds.
>
> No. If CL-USER::FOO is GC-ed, it is because the symbol is no long
> accessible. In particular, it is no longer interned in the CL-USER
> package. (Or you have removed the CL-USER package.) If READ
> encounters it again, it will intern a new symbol. Since there is no
> old symbol to apply EQ to, your problem does not arise.
There is the problem, though, that FIND-SYMBOL will behave differently
if you make the symbol go away, as will a number of other package operators.
You also lose any information attached to the symbol (value, function,
and plist slots.)
The Cliki.net site has a list of proposed extensions to CL. One that
I added was 'weak packages', which would be analogous to weak hash
tables. A symbol in a weak package could be uninterned at gc time
if the only references to it were from weak packages.
Paul
In article <·················@motorola.com>,
Paul Dietz <············@motorola.com> wrote:
> Harald Hanche-Olsen wrote:
> >
> > No. If CL-USER::FOO is GC-ed, it is because the symbol is no long
> > accessible. In particular, it is no longer interned in the CL-USER
> > package. (Or you have removed the CL-USER package.) If READ
> > encounters it again, it will intern a new symbol. Since there is no
> > old symbol to apply EQ to, your problem does not arise.
>
> There is the problem, though, that FIND-SYMBOL will behave differently
> if you make the symbol go away, as will a number of other package operators.
I'm not sure what you mean. If the symbol has been uninterned,
FIND-SYMBOL won't find it. Whether it has been GC'ed or not is
irrelevant.
--
Barry Margolin, ······@alum.mit.edu
Arlington, MA
*** PLEASE post questions in newsgroups, not directly to me ***
Barry Margolin wrote:
> I'm not sure what you mean. If the symbol has been uninterned,
> FIND-SYMBOL won't find it. Whether it has been GC'ed or not is
> irrelevant.
I thought it was being proposed that symbols be removed even
if they hadn't been uninterned, as long as nothing else refered
to them. If not, I misread.
Paul
+ "Paul F. Dietz" <·····@dls.net>:
| I thought it was being proposed that symbols be removed even
| if they hadn't been uninterned, as long as nothing else refered
| to them. If not, I misread.
I certainly never meant to suggest this. After all, an interned
symbol is definitely accessible through its package.
--
* Harald Hanche-Olsen <URL:http://www.math.ntnu.no/~hanche/>
- Debating gives most of us much more psychological satisfaction
than thinking does: but it deprives us of whatever chance there is
of getting closer to the truth. -- C.P. Snow
On Wed, 11 Aug 2004 20:35:37 +0200, Frode Vatvedt Fjeld wrote:
> "NicoD" <·······@netscape.net> writes:
>
>> Are the awnsers to 1, 2, 3 and 4 all yes?
>
> Basically yes, if in 3 you meant (setf (symbol-value ..) 10).
>
> An object is reclaimed by GC when it can prove that there's no
> (standard) way to get at a pointer to that object.
>
Hmm, is this really true? I think an implementation needs to hold
on to _interned_ symbols, otherwise the following would be hard to
implement:
(eq (intern "TEST") (read-from-string "test"))
A symbol is allways accessible (by its very nature as a "singleton") and
hence can't really be GCed. Of course, whatever is ponted to by the
symbol might get GCed.
Ralf Mattes
In article <···································@mh-freiburg.de>,
"R. Mattes" <··@mh-freiburg.de> wrote:
> On Wed, 11 Aug 2004 20:35:37 +0200, Frode Vatvedt Fjeld wrote:
>
> > "NicoD" <·······@netscape.net> writes:
> >
> >> Are the awnsers to 1, 2, 3 and 4 all yes?
> >
> > Basically yes, if in 3 you meant (setf (symbol-value ..) 10).
> >
> > An object is reclaimed by GC when it can prove that there's no
> > (standard) way to get at a pointer to that object.
> >
>
> Hmm, is this really true? I think an implementation needs to hold
> on to _interned_ symbols, otherwise the following would be hard to
> implement:
>
> (eq (intern "TEST") (read-from-string "test"))
>
> A symbol is allways accessible (by its very nature as a "singleton") and
> hence can't really be GCed. Of course, whatever is ponted to by the
> symbol might get GCed.
But the OP's questions were about *uninterned* symbols -- his examples
all used MAKE-SYMBOL. That's why the answers were all "yes".
--
Barry Margolin, ······@alum.mit.edu
Arlington, MA
*** PLEASE post questions in newsgroups, not directly to me ***
"R. Mattes" <··@mh-freiburg.de> writes:
> Hmm, is this really true? I think an implementation needs to hold
> on to _interned_ symbols, otherwise the following would be hard to
> implement:
>
> (eq (intern "TEST") (read-from-string "test"))
>
> A symbol is allways accessible (by its very nature as a "singleton") and
> hence can't really be GCed. Of course, whatever is ponted to by the
> symbol might get GCed.
The point is that symbols are not special in any way (pun
intended). An interned symbol will not be GC'ed not because it is
treated specially, but because the system maintains a map of all
packages (list-all-packages) and the interned symbol will be pointed
to by one of these packages.
On Wed, 11 Aug 2004 20:35:37 +0200, Frode Vatvedt Fjeld wrote:
>> An object is reclaimed by GC when it can prove that there's no
>> (standard) way to get at a pointer to that object.
"R. Mattes" <··@mh-freiburg.de> writes:
> Hmm, is this really true? I think an implementation needs to hold on
> to _interned_ symbols, otherwise the following would be hard to
> implement:
>
> (eq (intern "TEST") (read-from-string "test"))
>
> A symbol is allways accessible (by its very nature as a "singleton")
> and hence can't really be GCed. Of course, whatever is ponted to by
> the symbol might get GCed.
Well.. to be "interned" pretty much means that there /is/ a standard
way to get a pointer to the symbol (by looking up a string, which
typically means there's a hash-table or something somewhere in a
global variable that holds a pointer to the symbol object). So I don't
quite understand what your point is. And so loing as a symbol is
interned, I'm quite certain that the contents of the symbol's value
cell can't get reclaimed as garbage.
--
Frode Vatvedt Fjeld