I realized I have a doubt on some basic garbage collection issues. If
it helps, I refer to CMUCL under x86 Linux.
Suppose the Lisp image contains references to a number of A objects,
not necessarily CLOS instances, each of which has a reference to a B
object. If all references to A are removed, but the ones to B are
kept, are A objects garbage collected?
Paolo
--
Lisp Propulsion Laboratory log - http://www.paoloamoroso.it/log
From: Russell McManus
Subject: Re: If A->B and references to A (but not B) disappear, is A garbage collected?
Date:
Message-ID: <87vf61k2vf.fsf@cl-user.org>
Paolo Amoroso <·······@mclink.it> writes:
> I realized I have a doubt on some basic garbage collection issues. If
> it helps, I refer to CMUCL under x86 Linux.
>
> Suppose the Lisp image contains references to a number of A objects,
> not necessarily CLOS instances, each of which has a reference to a B
> object. If all references to A are removed, but the ones to B are
> kept, are A objects garbage collected?
I'm not sure I understand your question, but operating under the
assumption that I do, the rule is simply that reachable objects are
retained and unreachable ones (eventually) reclaimed.
To determine whether an object is reachable start with the set of
objects contained in global variables, stack variables, and current
machine register constants. Then add to this set all of the objects
that are pointed to by the objects in the root set, recursively.
Maybe you are running into a problem where CMUCL is holding onto a
reference erroneously?
HTH.
-russ
From: Arthur Lemmens
Subject: Re: If A->B and references to A (but not B) disappear, is A garbage collected?
Date:
Message-ID: <opsp5qq4lrk6vmsw@news.xs4all.nl>
Paolo Amoroso wrote:
> I realized I have a doubt on some basic garbage collection issues. If
> it helps, I refer to CMUCL under x86 Linux.
>
> Suppose the Lisp image contains references to a number of A objects,
> not necessarily CLOS instances, each of which has a reference to a B
> object. If all references to A are removed, but the ones to B are
> kept, are A objects garbage collected?
I'm not totally sure if I understand your question.
Maybe you should look at it the other way round. Every object that can
be referenced by your program (in its current and all possible future
states) must be kept. Everything else may be collected by the garbage
collector. But you usually don't know when (or even if) the garbage
collector will do that.
In your example: if there is no way that your program can refer to
any A or B objects, it's reasonable to expect that the memory that's
used by these objects will sooner or later be reclaimed (i.e. made
available for new objects).
Arthur
From: Pascal Bourguignon
Subject: Re: If A->B and references to A (but not B) disappear, is A garbage collected?
Date:
Message-ID: <87br7tcz6i.fsf@thalassa.informatimago.com>
Paolo Amoroso <·······@mclink.it> writes:
> I realized I have a doubt on some basic garbage collection issues. If
> it helps, I refer to CMUCL under x86 Linux.
>
> Suppose the Lisp image contains references to a number of A objects,
> not necessarily CLOS instances, each of which has a reference to a B
> object. If all references to A are removed, but the ones to B are
> kept, are A objects garbage collected?
Yes.
Assuming two global variables *v1* and *v2*, referencing the data
object A, C and B with no other references:
*v1* ---> A ---> B
^
|
*v2* ---> C -----+
[ eg.:
(defparameter *v1* (cons "B" nil))
(defparameter *v2* (cons (car *v1*) nil))
]
If you break the link *v1* ---> A [ eg.: (setf *v1* nil) ]
then A can be garbage collected (the first cons allocated above).
But since B is still accessible thru *v2* via C, it won't.
--
__Pascal Bourguignon__ http://www.informatimago.com/
Kitty like plastic.
Confuses for litter box.
Don't leave tarp around.
From: Thomas F. Burdick
Subject: Re: If A->B and references to A (but not B) disappear, is A garbage collected?
Date:
Message-ID: <xcvsm1491sc.fsf@conquest.OCF.Berkeley.EDU>
Paolo Amoroso <·······@mclink.it> writes:
> I realized I have a doubt on some basic garbage collection issues. If
> it helps, I refer to CMUCL under x86 Linux.
>
> Suppose the Lisp image contains references to a number of A objects,
> not necessarily CLOS instances, each of which has a reference to a B
> object. If all references to A are removed, but the ones to B are
> kept, are A objects garbage collected?
They can be. However, there's no guarantee of when or if the GC will
run, or what regions of the heap it will consider when it does run.
In the case of CMUCL on x86, the GC is generational and conservative,
so forcing it to collect everything that it can, requires doing a full
GC and scrubbing the stack first.
Are you hopinhg for timely collection or eventual collection?
···@conquest.OCF.Berkeley.EDU (Thomas F. Burdick) writes:
> Are you hopinhg for timely collection or eventual collection?
Eventual collection would be fine.
Paolo
--
Why Lisp? http://lisp.tech.coop/RtL%20Highlight%20Film
Recommended Common Lisp libraries/tools (see also http://clrfi.alu.org):
- ASDF/ASDF-INSTALL: system building/installation
- CL-PPCRE: regular expressions
- UFFI: Foreign Function Interface
From: Thomas F. Burdick
Subject: Re: If A->B and references to A (but not B) disappear, is A garbage collected?
Date:
Message-ID: <xcvpsw88yh2.fsf@conquest.OCF.Berkeley.EDU>
Paolo Amoroso <·······@mclink.it> writes:
> ···@conquest.OCF.Berkeley.EDU (Thomas F. Burdick) writes:
>
> > Are you hopinhg for timely collection or eventual collection?
>
> Eventual collection would be fine.
In that case, you probably don't have to worry about it. The case
where the GC's conservatism can bite you is if you grow the stack very
very deep, passing references to otherwise-GC'able objects, and then
never grow that stack that much again. The old frames won't be
overwritten, the references in them will be considered potentially
valid, and the GC will never be able to free the garbage.
If this is a possiblity for your app, ask about stack-scrubbing on the
CMUCL lists, or dig through the archives. I remember some discussion
of this a while back, but didn't pay too much attention, because I
manage to mostly avoid x86.