How can I force the deletion of an object? I need to test some code
that involves CFFI and finalization. I have the following usage in
mind:
;; create object
(defparameter *foo-instance* (make-instance 'foo))
;; play around with *foo-instance*, code not shown here
;; delete foo
(setf *foo-instance* nil)
;; now the object is ready to be GC'd, how can I force the GC to do
;; it?
I am using SBCL.
Tamas
On 12 Jul., 14:40, Tamas Papp <······@gmail.com> wrote:
> How can I force the deletion of an object? I need to test some code
> that involves CFFI and finalization. I have the following usage in
> mind:
>
> ;; create object
> (defparameter *foo-instance* (make-instance 'foo))
>
> ;; play around with *foo-instance*, code not shown here
>
> ;; delete foo
> (setf *foo-instance* nil)
>
> ;; now the object is ready to be GC'd, how can I force the GC to do
> ;; it?
>
> I am using SBCL.
A garbage collector is some kind of resource manager for a very
particular resource - memory. It is not a good idea to try to use the
garbage collector to manage other resources. Memory allocated using
CFFI is not the same kind of resource as the "managed memory" of the
lisp system. While finalizers are a good thing as a fallback solution
and to make applications generally more robust, they should not be
used as the base of a resource management system. You cannot rely on
when a finalizer gets called or even if it is called at all.
If possible, design your program so that the resources are used in
some defined dynamic extent; you can then use UNWIND-PROTECT to ensure
proper deallocation (in the spirit of WITH-OPEN-FILE).
If your question is really about "deleting" CLOS objects then you can
use CHANGE-CLASS for something like that. Just define a class without
slots named DELETED-OBJECT and instead of (setf *foo-instance* nil)
you do (change-class *foo-instance* 'deleted-object). You can
implement a method for UPDATE-INSTANCE-FOR-DIFFERENT-CLASS with it's
second parameter specialized to DELETED-OBJECT if you want to free
other resources this object is associated with (like sockets, ffi-
memory a. s. o.).
ciao,
Jochen
On 12 Jul., 15:40, ·····@codeartist.org" <····@codeartist.org> wrote:
> If your question is really about "deleting" CLOS objects then you can
> use CHANGE-CLASS for something like that. Just define a class without
> slots named DELETED-OBJECT and instead of (setf *foo-instance* nil)
> you do (change-class *foo-instance* 'deleted-object). You can
> implement a method for UPDATE-INSTANCE-FOR-DIFFERENT-CLASS with it's
> second parameter specialized to DELETED-OBJECT if you want to free
> other resources this object is associated with (like sockets, ffi-
> memory a. s. o.).
I remember reading about this way of object management in a post by
Erik Naggum seven years ago.
See http://groups.google.de/group/comp.lang.lisp/tree/browse_frm/thread/db3506494c18656c/da0656077f9c56e6?rnum=23
for more Details.
ciao,
Jochen
···@codeartist.org" <··@codeartist.org> writes:
> On 12 Jul., 15:40, ·····@codeartist.org" <····@codeartist.org> wrote:
>
>> If your question is really about "deleting" CLOS objects then you can
>> use CHANGE-CLASS for something like that. Just define a class without
>> slots named DELETED-OBJECT and instead of (setf *foo-instance* nil)
>> you do (change-class *foo-instance* 'deleted-object). You can
>> implement a method for UPDATE-INSTANCE-FOR-DIFFERENT-CLASS with it's
>> second parameter specialized to DELETED-OBJECT if you want to free
>> other resources this object is associated with (like sockets, ffi-
>> memory a. s. o.).
>
> I remember reading about this way of object management in a post by
> Erik Naggum seven years ago.
>
> See http://groups.google.de/group/comp.lang.lisp/tree/browse_frm/thread/db3506494c18656c/da0656077f9c56e6?rnum=23
> for more Details.
>
Hi Jochen,
Since this is your second post on the subject, I feel that I should
point out that either you didn't understand my question (or maybe I
wasn't clear). I agree with everything you said about not relying
finalizers: indeed, I have explicit methods to destroy those objects
(by calling the appropriate C functions), finalizers are just a
fallback.
However, I wanted to _test_ that this fallback works, even if I am not
using it.
I found my solution: CMUCL's gc works in SBCL too. I am beginning to
think that when I want to know something in SBCL, I should look at
CMUCL's documentation first ;-)
I am still looking for a way to "delete" objects, if I need it in the
future.
Tamas
On Jul 12, 5:53 pm, Tamas Papp <······@gmail.com> wrote:
> I found my solution: CMUCL's gc works in SBCL too. I am beginning to
> think that when I want to know something in SBCL, I should look at
> CMUCL's documentation first ;-)
Might I be so bold as to suggest the SBCL documentation?
http://www.sbcl.org/manual/
http://www.sbcl.org/manual/Garbage-Collection.html#Garbage-Collection
Furthermore, SBCL specific question are best asked on the "sbcl-help"
mailing list. (Fact which admitted isn't particularly well advertised
on
www.sbcl.org.)
https://lists.sourceforge.net/lists/listinfo/sbcl-help
There is no guarantee that anyone with real knowledge of SBCL
particulars
will see your post on comp.lang.lisp.
Cheers,
-- Nikodemus
On 12 Jul., 16:53, Tamas Papp <······@gmail.com> wrote:
> ·····@codeartist.org" <····@codeartist.org> writes:
> > On 12 Jul., 15:40, ·····@codeartist.org" <····@codeartist.org> wrote:
>
> >> If your question is really about "deleting" CLOS objects then you can
> >> use CHANGE-CLASS for something like that. Just define a class without
> >> slots named DELETED-OBJECT and instead of (setf *foo-instance* nil)
> >> you do (change-class *foo-instance* 'deleted-object). You can
> >> implement a method for UPDATE-INSTANCE-FOR-DIFFERENT-CLASS with it's
> >> second parameter specialized to DELETED-OBJECT if you want to free
> >> other resources this object is associated with (like sockets, ffi-
> >> memory a. s. o.).
>
> > I remember reading about this way of object management in a post by
> > Erik Naggum seven years ago.
>
> > Seehttp://groups.google.de/group/comp.lang.lisp/tree/browse_frm/thread/d...
> > for more Details.
>
> Hi Jochen,
>
> Since this is your second post on the subject, I feel that I should
> point out that either you didn't understand my question (or maybe I
> wasn't clear). I agree with everything you said about not relying
> finalizers: indeed, I have explicit methods to destroy those objects
> (by calling the appropriate C functions), finalizers are just a
> fallback.
Ok... do I understand you right that you want to trigger the
finalizers? Well the answer (which it seems you have already found) is
maybe to do a full GC and hope that this is enough in SBCL to pick up
your garbage and run the finalizers on it.
> However, I wanted to _test_ that this fallback works, even if I am not
> using it.
That wasn't particularily clear to me reading your post ;-).
> I found my solution: CMUCL's gc works in SBCL too. I am beginning to
> think that when I want to know something in SBCL, I should look at
> CMUCL's documentation first ;-)
A good advise!
> I am still looking for a way to "delete" objects, if I need it in the
> future.
If what I mentioned as a solution is not what you mean by "deleting"
objects what do you really mean?
(setf *foo-instance* nil)
isn't really "deleting" and object to me. It's changing a binding but
has nothing to do with the instance as is. I cannot imagine that you
could actually mean to deallocate a lisp object on demand do you? So
what kind of objects do you actually mean and what do you mean if you
say you want to delete those?
ciao,
Jochen
Tamas Papp <······@gmail.com> writes:
> I found my solution: CMUCL's gc works in SBCL too. I am beginning to
> think that when I want to know something in SBCL, I should look at
> CMUCL's documentation first ;-)
>
> I am still looking for a way to "delete" objects, if I need it in
> the future.
Can you even define what "deleting" in this context is supposed to
mean?
Suppose there were an operator, DELETE-OBJECT, that did what you think
it's supposed to do, and consider the following:
(defvar *v1*)
(defvar *v2*)
(setf *v1* (make-instance ...))
(setf *v2* *v1*)
(delete-object *v1*)
What should the value of *V2* be? And how might the implementation
track whether *V2* ought to be affected by DELETE-OBJECT?
Consequently, the garbage collector does not do what you think it
does, in general. In the transcript below [1], do you get why the
space allocated for *BIG-THING* isn't released until the third call to
GC? (Hint: don't try experimenting with this in SLIME.)
--
RmK
[1]
$ sbcl --noinform
* (room)
Dynamic space usage is: 36,392,768 bytes.
Read-only space usage is: 1,872 bytes.
Static space usage is: 1,128 bytes.
Control stack usage is: 1,344 bytes.
Binding stack usage is: 320 bytes.
Garbage collection is currently enabled.
Breakdown for dynamic space:
12,231,704 bytes for 10,940 code objects.
9,256,176 bytes for 1,157,022 cons objects.
4,973,704 bytes for 115,717 instance objects.
4,436,576 bytes for 78,028 simple-vector objects.
5,495,008 bytes for 188,730 other objects.
36,393,168 bytes for 1,550,437 dynamic objects (space total.)
* (setf *print-array* nil)
NIL
* (defvar *big-thing* (make-array (* 100 1024 1024)
:element-type '(unsigned-byte 8)))
*BIG-THING*
* (room)
Dynamic space usage is: 131,232,368 bytes.
Read-only space usage is: 1,872 bytes.
Static space usage is: 1,128 bytes.
Control stack usage is: 1,344 bytes.
Binding stack usage is: 320 bytes.
Garbage collection is currently enabled.
Breakdown for dynamic space:
105,075,120 bytes for 977 simple-array-unsigned-byte-8 objects.
12,228,448 bytes for 10,926 code objects.
13,928,856 bytes for 653,400 other objects.
131,232,424 bytes for 665,303 dynamic objects (space total.)
* *big-thing*
#<(SIMPLE-ARRAY (UNSIGNED-BYTE 8) (104857600)) {51530007}>
* (setf *big-thing* nil)
NIL
* (gc)
NIL
* (room)
Dynamic space usage is: 131,231,960 bytes.
Read-only space usage is: 1,872 bytes.
Static space usage is: 1,128 bytes.
Control stack usage is: 1,344 bytes.
Binding stack usage is: 320 bytes.
Garbage collection is currently enabled.
Breakdown for dynamic space:
105,075,120 bytes for 977 simple-array-unsigned-byte-8 objects.
12,228,448 bytes for 10,926 code objects.
13,928,456 bytes for 653,404 other objects.
131,232,024 bytes for 665,307 dynamic objects (space total.)
* (gc)
NIL
* (room)
Dynamic space usage is: 131,232,128 bytes.
Read-only space usage is: 1,872 bytes.
Static space usage is: 1,128 bytes.
Control stack usage is: 1,344 bytes.
Binding stack usage is: 320 bytes.
Garbage collection is currently enabled.
Breakdown for dynamic space:
105,075,120 bytes for 977 simple-array-unsigned-byte-8 objects.
12,228,448 bytes for 10,926 code objects.
13,928,640 bytes for 653,421 other objects.
131,232,208 bytes for 665,324 dynamic objects (space total.)
* (gc)
NIL
* (room)
Dynamic space usage is: 26,305,320 bytes.
Read-only space usage is: 1,872 bytes.
Static space usage is: 1,128 bytes.
Control stack usage is: 1,344 bytes.
Binding stack usage is: 320 bytes.
Garbage collection is currently enabled.
Breakdown for dynamic space:
12,226,272 bytes for 10,918 code objects.
3,355,488 bytes for 77,949 instance objects.
3,276,312 bytes for 53,272 simple-vector objects.
3,190,928 bytes for 398,866 cons objects.
4,256,368 bytes for 120,796 other objects.
26,305,368 bytes for 661,801 dynamic objects (space total.)
Richard M Kreuter <·······@progn.net> writes:
> Tamas Papp <······@gmail.com> writes:
>
>> I found my solution: CMUCL's gc works in SBCL too. I am beginning to
>> think that when I want to know something in SBCL, I should look at
>> CMUCL's documentation first ;-)
>>
>> I am still looking for a way to "delete" objects, if I need it in
>> the future.
>
> Can you even define what "deleting" in this context is supposed to
> mean?
Deleting an object in this context is something that calls the
finalizer. If you read the original post, I explicitly asked for
advice on how to test my finalizer code.
> Suppose there were an operator, DELETE-OBJECT, that did what you think
> it's supposed to do, and consider the following:
>
> (defvar *v1*)
> (defvar *v2*)
>
> (setf *v1* (make-instance ...))
> (setf *v2* *v1*)
>
> (delete-object *v1*)
>
> What should the value of *V2* be? And how might the implementation
> track whether *V2* ought to be affected by DELETE-OBJECT?
I see your point, thanks.
> Consequently, the garbage collector does not do what you think it
> does, in general. In the transcript below [1], do you get why the
> space allocated for *BIG-THING* isn't released until the third call to
> GC? (Hint: don't try experimenting with this in SLIME.)
No, I don't get it. Can you please explain?
Tamas
>
> --
> RmK
>
> [1]
> $ sbcl --noinform
> * (room)
>
> Dynamic space usage is: 36,392,768 bytes.
> Read-only space usage is: 1,872 bytes.
> Static space usage is: 1,128 bytes.
> Control stack usage is: 1,344 bytes.
> Binding stack usage is: 320 bytes.
> Garbage collection is currently enabled.
>
> Breakdown for dynamic space:
> 12,231,704 bytes for 10,940 code objects.
> 9,256,176 bytes for 1,157,022 cons objects.
> 4,973,704 bytes for 115,717 instance objects.
> 4,436,576 bytes for 78,028 simple-vector objects.
> 5,495,008 bytes for 188,730 other objects.
> 36,393,168 bytes for 1,550,437 dynamic objects (space total.)
> * (setf *print-array* nil)
>
> NIL
> * (defvar *big-thing* (make-array (* 100 1024 1024)
> :element-type '(unsigned-byte 8)))
>
> *BIG-THING*
> * (room)
>
> Dynamic space usage is: 131,232,368 bytes.
> Read-only space usage is: 1,872 bytes.
> Static space usage is: 1,128 bytes.
> Control stack usage is: 1,344 bytes.
> Binding stack usage is: 320 bytes.
> Garbage collection is currently enabled.
>
> Breakdown for dynamic space:
> 105,075,120 bytes for 977 simple-array-unsigned-byte-8 objects.
> 12,228,448 bytes for 10,926 code objects.
> 13,928,856 bytes for 653,400 other objects.
> 131,232,424 bytes for 665,303 dynamic objects (space total.)
> * *big-thing*
>
> #<(SIMPLE-ARRAY (UNSIGNED-BYTE 8) (104857600)) {51530007}>
> * (setf *big-thing* nil)
>
> NIL
> * (gc)
>
> NIL
> * (room)
>
> Dynamic space usage is: 131,231,960 bytes.
> Read-only space usage is: 1,872 bytes.
> Static space usage is: 1,128 bytes.
> Control stack usage is: 1,344 bytes.
> Binding stack usage is: 320 bytes.
> Garbage collection is currently enabled.
>
> Breakdown for dynamic space:
> 105,075,120 bytes for 977 simple-array-unsigned-byte-8 objects.
> 12,228,448 bytes for 10,926 code objects.
> 13,928,456 bytes for 653,404 other objects.
> 131,232,024 bytes for 665,307 dynamic objects (space total.)
> * (gc)
>
> NIL
> * (room)
>
> Dynamic space usage is: 131,232,128 bytes.
> Read-only space usage is: 1,872 bytes.
> Static space usage is: 1,128 bytes.
> Control stack usage is: 1,344 bytes.
> Binding stack usage is: 320 bytes.
> Garbage collection is currently enabled.
>
> Breakdown for dynamic space:
> 105,075,120 bytes for 977 simple-array-unsigned-byte-8 objects.
> 12,228,448 bytes for 10,926 code objects.
> 13,928,640 bytes for 653,421 other objects.
> 131,232,208 bytes for 665,324 dynamic objects (space total.)
> * (gc)
>
> NIL
> * (room)
>
> Dynamic space usage is: 26,305,320 bytes.
> Read-only space usage is: 1,872 bytes.
> Static space usage is: 1,128 bytes.
> Control stack usage is: 1,344 bytes.
> Binding stack usage is: 320 bytes.
> Garbage collection is currently enabled.
>
> Breakdown for dynamic space:
> 12,226,272 bytes for 10,918 code objects.
> 3,355,488 bytes for 77,949 instance objects.
> 3,276,312 bytes for 53,272 simple-vector objects.
> 3,190,928 bytes for 398,866 cons objects.
> 4,256,368 bytes for 120,796 other objects.
> 26,305,368 bytes for 661,801 dynamic objects (space total.)
Tamas Papp <······@gmail.com> wrote:
+---------------
| Richard M Kreuter <·······@progn.net> writes:
| > Consequently, the garbage collector does not do what you think it
| > does, in general. In the transcript below [1], do you get why the
| > space allocated for *BIG-THING* isn't released until the third call to
| > GC? (Hint: don't try experimenting with this in SLIME.)
|
| No, I don't get it. Can you please explain?
+---------------
Well, here's one big hint [spoiler]:
http://alu.org/HyperSpec/Body/var_stcm_ststcm_ststst.html
http://alu.org/HyperSpec/Body/var_slcm_slslcm_slslsl.html
-Rob
-----
Rob Warnock <····@rpw3.org>
627 26th Avenue <URL:http://rpw3.org/>
San Mateo, CA 94403 (650)572-2607
····@rpw3.org (Rob Warnock) writes:
> Tamas Papp <······@gmail.com> wrote:
> +---------------
> | Richard M Kreuter <·······@progn.net> writes:
> | > Consequently, the garbage collector does not do what you think it
> | > does, in general. In the transcript below [1], do you get why the
> | > space allocated for *BIG-THING* isn't released until the third call to
> | > GC? (Hint: don't try experimenting with this in SLIME.)
> |
> | No, I don't get it. Can you please explain?
> +---------------
>
> Well, here's one big hint [spoiler]:
>
> http://alu.org/HyperSpec/Body/var_stcm_ststcm_ststst.html
> http://alu.org/HyperSpec/Body/var_slcm_slslcm_slslsl.html
Thanks, I didn't know about * & co.
Tamas
Tamas Papp <······@gmail.com> writes:
> ····@rpw3.org (Rob Warnock) writes:
>
>> Tamas Papp <······@gmail.com> wrote:
>> +---------------
>> | Richard M Kreuter <·······@progn.net> writes:
>> | > Consequently, the garbage collector does not do what you think it
>> | > does, in general. In the transcript below [1], do you get why the
>> | > space allocated for *BIG-THING* isn't released until the third call to
>> | > GC? (Hint: don't try experimenting with this in SLIME.)
> [...]
> Thanks, I didn't know about * & co.
And SLIME has an even longer history list! ;-)
--
__Pascal Bourguignon__ http://www.informatimago.com/
NOTE: The most fundamental particles in this product are held
together by a "gluing" force about which little is currently known
and whose adhesive power can therefore not be permanently
guaranteed.
On 13 Jul., 10:30, Tamas Papp <······@gmail.com> wrote:
> Richard M Kreuter <·······@progn.net> writes:
>
> > Tamas Papp <······@gmail.com> writes:
>
> >> I found my solution: CMUCL's gc works in SBCL too. I am beginning to
> >> think that when I want to know something in SBCL, I should look at
> >> CMUCL's documentation first ;-)
>
> >> I am still looking for a way to "delete" objects, if I need it in
> >> the future.
>
> > Can you even define what "deleting" in this context is supposed to
> > mean?
>
> Deleting an object in this context is something that calls the
> finalizer. If you read the original post, I explicitly asked for
> advice on how to test my finalizer code.
I thought you already found a solution to that?
--
Jochen
···@codeartist.org" <··@codeartist.org> writes:
> On 13 Jul., 10:30, Tamas Papp <······@gmail.com> wrote:
>> Richard M Kreuter <·······@progn.net> writes:
>>
>> > Tamas Papp <······@gmail.com> writes:
>>
>> >> I found my solution: CMUCL's gc works in SBCL too. I am beginning to
>> >> think that when I want to know something in SBCL, I should look at
>> >> CMUCL's documentation first ;-)
>>
>> >> I am still looking for a way to "delete" objects, if I need it in
>> >> the future.
>>
>> > Can you even define what "deleting" in this context is supposed to
>> > mean?
>>
>> Deleting an object in this context is something that calls the
>> finalizer. If you read the original post, I explicitly asked for
>> advice on how to test my finalizer code.
>
> I thought you already found a solution to that?
I did, I was just clarifying the question since Richard asked.
Thanks for everyone who posted answers, I learned about * and also
found a solution, so I am happy ;-)
Tamas