Hello,
After much help already, I think I need some training in proper object removal.
When my application creates an object and stores it in an OrderedCollection, and than wants to delete it, I am trying to do so quite explicitly with something like:
DataManager>>deleteSelectedAbstractors self selected do: [:each | self abstractors remove: each. each := nil. ]
which removes the object from my application (it's collection), and yet when I look for my object in the system with
DataAbstractor allInstances.
I still see the object I removed, even with an explicit Smalltalk garbageCollect or garbageCollectMost. Anything I create just seems to hang around forever.
Any help understanding what I need to do to make sure my objects really go away when I am done with them would be greatly appreciated!
Rob
Hello Rob,
RR> After much help already, I think I need some training in proper object removal.
RR> DataAbstractor allInstances.
if you inspect this you get an inspector on an Array. To the left select any entry with a left click (on Windows) and select "objects pointing to this value". You get another inspector with an array of the objects pointing to the object you can't delete.
Again inspecting one of these objects you can see how it points to your original object. This might give you a clue. And manually deleting these references (setting them to nil in the inspector) will eventually free your original object for garbage collection.
If some of the objects you find are WeakArray or such you are in the (to me) murky area of finalization and weak references. Squeak dev would be the place to ask.
You don't state the size of your problem. Is it three or is it thousands of instances hanging around?.
I once tried the pointer finder tool but wasn't satisfied with it.
And the swiki has a page on "cleaning up junk".
RR> I still see the object I removed, even with an explicit RR> Smalltalk garbageCollect or garbageCollectMost.
RR> Anything I create seems to hang around forever.
Sometimes saving and reloading an image does a more thorough job than garbageCollect. Maybe because of the above mentioned weak references.
On Wed, Jun 4, 2008 at 12:45 AM, Herbert König herbertkoenig@gmx.net wrote:
if you inspect this you get an inspector on an Array. To the left select any entry with a left click (on Windows) and select "objects pointing to this value". You get another inspector with an array of the objects pointing to the object you can't delete.
Again inspecting one of these objects you can see how it points to your original object. This might give you a clue. And manually deleting these references (setting them to nil in the inspector) will eventually free your original object for garbage collection.
This is helpful...and leads me to explain a little more because I was making an assumption that might not be correct...
I am writing a little arbitrary data collection application using Squeak and Aida. I can build forms with tabbed pages and add various fields, move them up and down, give them different labels, that whole thing. In short, I can create lots of objects within objects within objects.
My main classes are:
DataManager -- Manages a list of "DataAbstractors" DataAbstractor -- Manages the "DynamicRecordPage(s)" (basically groups of fields) DynamicRecordPage -- Manages "FieldDefinition(s)" DynamicRecord -- Holds the data and handles arbitrary messages based on a FieldDefinition.
I have been assuming that if I get rid of a DataAbstractor, all it's underlying objects would just "go away" as well (Pages and Records).
Do you have to explicitly remove the child objects BEFORE removing a parent object to ensure that it is removed properly?
If some of the objects you find are WeakArray or such you are in the
(to me) murky area of finalization and weak references. Squeak dev would be the place to ask.
Fortunately, these are all recognizable objects that I would expect!
You don't state the size of your problem. Is it three or is it
thousands of instances hanging around?.
Well, it is a few right now, but just grows continually as I use it! Nothing ever goes away, so I figure it will BE thousands if I don't figure this out. Every now and then I just save my project, blow it away, garbage collect, and reload everything. So far, that's the only way I can seem to get rid of anything!
I once tried the pointer finder tool but wasn't satisfied with it.
And the swiki has a page on "cleaning up junk".
RR> I still see the object I removed, even with an explicit RR> Smalltalk garbageCollect or garbageCollectMost.
RR> Anything I create seems to hang around forever.
Sometimes saving and reloading an image does a more thorough job than garbageCollect. Maybe because of the above mentioned weak references.
Thanks for your help...
Rob
On Wed, 2008-06-04 at 00:04 -0400, Rob Rothwell wrote:
Hello,
After much help already, I think I need some training in proper object removal.
When my application creates an object and stores it in an OrderedCollection, and than wants to delete it, I am trying to do so quite explicitly with something like:
DataManager>>deleteSelectedAbstractors self selected do: [:each | self abstractors remove: each. each := nil. ]
which removes the object from my application (it's collection), and yet when I look for my object in the system with
DataAbstractor allInstances.
I still see the object I removed, even with an explicit Smalltalk garbageCollect or garbageCollectMost. Anything I create just seems to hang around forever.
Any help understanding what I need to do to make sure my objects really go away when I am done with them would be greatly appreciated!
The objects are still referenced in the collection you get from self selected. The line with "each := nil" is useless as each is only a temporary variable. I assume that you want to empty the selected collection as well. you could do
DataManager>>deleteSelectedAbstractors self selected copy do: [:each | self abstractors remove: each. self selected remove: each. ]
regards,
Norbert
On Wed, 04 Jun 2008 09:55:11 +0200, Norbert Hartl wrote:
On Wed, 2008-06-04 at 00:04 -0400, Rob Rothwell wrote:
Hello,
After much help already, I think I need some training in proper object removal.
When my application creates an object and stores it in an OrderedCollection, and than wants to delete it, I am trying to do so quite explicitly with something like:
DataManager>>deleteSelectedAbstractors self selected do: [:each | self abstractors remove: each. each := nil. ]
which removes the object from my application (it's collection), and yet when I look for my object in the system with
DataAbstractor allInstances.
I still see the object I removed, even with an explicit Smalltalk garbageCollect or garbageCollectMost. Anything I create just seems to hang around forever.
Any help understanding what I need to do to make sure my objects really go away when I am done with them would be greatly appreciated!
The objects are still referenced in the collection you get from self selected. The line with "each := nil" is useless as each is only a temporary variable.
Not 100% useless, since temporary variables (and arguments, for that matter) survive any attempt, from within the same method, to garbage collect them:
{'this ', 'and ', 'that'} collect: [:each | ]. Smalltalk garbageCollect. {thisContext tempAt: 1} inspect
first line: create some object and make a temp var point to it. second line: invoke GC. third line: see what's still pointed to by the temp var.
/Klaus
I assume that you want to empty the selected collection as well. you could do
DataManager>>deleteSelectedAbstractors self selected copy do: [:each | self abstractors remove: each. self selected remove: each. ]
regards,
Norbert
On 04.06.2008, at 10:32, Klaus D. Witzel wrote:
On Wed, 04 Jun 2008 09:55:11 +0200, Norbert Hartl wrote:
The objects are still referenced in the collection you get from self selected. The line with "each := nil" is useless as each is only a temporary variable.
Not 100% useless, since temporary variables (and arguments, for that matter) survive any attempt, from within the same method, to garbage collect them:
{'this ', 'and ', 'that'} collect: [:each | ]. Smalltalk garbageCollect. {thisContext tempAt: 1} inspect
first line: create some object and make a temp var point to it. second line: invoke GC. third line: see what's still pointed to by the temp var.
Yikes. Klaus, please keep the hair-splitting to squeak-dev if possible.
Assigning to a block parameter is just wrong. Setting temps to nil is unnecessary in any normal method. If your code actually needs to worry about this, then you left the beginner playground.
Rob: Here's a recipe to find out what is keeping your instances from being garbage-collected:
http://wiki.squeak.org/squeak/2631
- Bert -
On Wed, Jun 4, 2008 at 6:12 AM, Bert Freudenberg bert@freudenbergs.de wrote:
Yikes. Klaus, please keep the hair-splitting to squeak-dev if possible.
Assigning to a block parameter is just wrong. Setting temps to nil is unnecessary in any normal method. If your code actually needs to worry about this, then you left the beginner playground.
I was hoping that was not the case! I WANT to be a beginner right now, not understanding something simple!
Rob: Here's a recipe to find out what is keeping your instances from being
garbage-collected:
Thanks,
Rob
On Wed, 04 Jun 2008 12:12:59 +0200, Bert Freudenberg wrote:
On 04.06.2008, at 10:32, Klaus D. Witzel wrote:
On Wed, 04 Jun 2008 09:55:11 +0200, Norbert Hartl wrote:
The objects are still referenced in the collection you get from self selected. The line with "each := nil" is useless as each is only a temporary variable.
Not 100% useless, since temporary variables (and arguments, for that matter) survive any attempt, from within the same method, to garbage collect them:
{'this ', 'and ', 'that'} collect: [:each | ]. Smalltalk garbageCollect. {thisContext tempAt: 1} inspect
first line: create some object and make a temp var point to it. second line: invoke GC. third line: see what's still pointed to by the temp var.
Yikes. Klaus, please keep the hair-splitting to squeak-dev if possible.
Ah. Didn't know that enumerating+removing with a block with argument + GC'ing in the same method, belongs to hair-splitting. Instead, I always thought that's one of the reasons that at least one to-be-removed object is guaranteed to not go away.
But anyways, thanks for letting me know ;)
Assigning to a block parameter is just wrong.
You better read before you write (the way you most often do indeed ;) then you'd find that I didn't write any assignment to anything. Instead, I ignored that and pointed to a potential beginner's problem. Sorry you didn't like that ;)
Setting temps to nil is unnecessary in any normal method. If your code actually needs to worry about this, then you left the beginner playground.
And if he does removal+GC+check for success in the same method? I cannot see whether someone just copies arbitrary statements given in a response to a question, or carefully puts them into separate methods, in his code in his .image, now or never ;)
Rob: Here's a recipe to find out what is keeping your instances from being garbage-collected:
http://wiki.squeak.org/squeak/2631
- Bert -
On Wed, Jun 4, 2008 at 8:41 AM, Klaus D. Witzel klaus.witzel@cobss.com wrote:
{'this ', 'and ', 'that'} collect: [:each | ].
Smalltalk garbageCollect. {thisContext tempAt: 1} inspect
first line: create some object and make a temp var point to it. second line: invoke GC. third line: see what's still pointed to by the temp var.
So...if I do line 1, then line 3, should I see items in the Array, or just the Array itself.
This is all very interesting, because in my application I am creating lots of collections of objects maintaining parent/child pointers, and I have obviously just done it WRONG!
Chasing pointers and objects is showing me that when I remove objects from my collections, I need to do that "all the way down," I think...
Thank you for helping my brain move in the right direction.
Rob
On Wed, 04 Jun 2008 15:20:05 +0200, Rob Rothwell wrote:
On Wed, Jun 4, 2008 at 8:41 AM, Klaus D. Witzel wrote:
{'this ', 'and ', 'that'} collect: [:each | ].
Smalltalk garbageCollect. {thisContext tempAt: 1} inspect
first line: create some object and make a temp var point to it. second line: invoke GC. third line: see what's still pointed to by the temp var.
So...if I do line 1, then line 3, should I see items in the Array, or just the Array itself.
What you want to see (according to your question about object removal) is just the empty array; and what I wanted to point out (without hair-splitting ;) is, that when you GC+check this within the same method, it *must* fail.
In Smalltalk it's very easy to script the removal+GC+check, for example in a workspace or add GC+check temporarily in a debugger session; that was my concern.
This is all very interesting, because in my application I am creating lots of collections of objects maintaining parent/child pointers, and I have obviously just done it WRONG!
A good example for maintaining parent/child objects, which works perfectly, is Smalltalk's #addSubclass: #removeSubclass: (both on the instance side of Class); when you check these two methods think that 'superclass' is your parent pointer.
Chasing pointers and objects is showing me that when I remove objects from my collections, I need to do that "all the way down," I think...
Thank you for helping my brain move in the right direction.
Rob
On Wed, Jun 4, 2008 at 9:41 AM, Klaus D. Witzel klaus.witzel@cobss.com wrote:
What you want to see (according to your question about object removal) is just the empty array; and what I wanted to point out (without hair-splitting ;) is, that when you GC+check this within the same method, it *must* fail.
I guess it would have to, wouldn't it?
In Smalltalk it's very easy to script the removal+GC+check, for example in a
workspace or add GC+check temporarily in a debugger session; that was my concern.
A good example for maintaining parent/child objects, which works perfectly, is Smalltalk's #addSubclass: #removeSubclass: (both on the instance side of Class); when you check these two methods think that 'superclass' is your parent pointer.
Thanks for pointing this out--maybe I can learn something and get this working properly!
Rob
On 04.06.2008, at 15:20, Rob Rothwell wrote:
On Wed, Jun 4, 2008 at 8:41 AM, Klaus D. Witzel <klaus.witzel@cobss.com
wrote:
{'this ', 'and ', 'that'} collect: [:each | ]. Smalltalk garbageCollect. {thisContext tempAt: 1} inspect
first line: create some object and make a temp var point to it. second line: invoke GC. third line: see what's still pointed to by the temp var.
So...if I do line 1, then line 3, should I see items in the Array, or just the Array itself.
This is all very interesting, because in my application I am creating lots of collections of objects maintaining parent/child pointers, and I have obviously just done it WRONG!
Chasing pointers and objects is showing me that when I remove objects from my collections, I need to do that "all the way down," I think...
Normally you do not need to do this "all the way down". Say you have a tree of objects, where the parent points to its children, and the children each back to its parent. Then it is sufficient to remove one child to have the whole subtree rooted at the child go away. There is no need to "delete" all the children's children. Also, the "back pointers" do no harm. But it is important that there are no other references to these objects - no inspectors, debuggers, etc.
As soon as there is no "path" from a global object to your object, it is subject to garbage collection (which will happen later, not immediately). The #allInstances method still finds these "unreachable" objects, because it simply looks at each and every object that was not yet gc'ed.
- Bert -
On Wed, 2008-06-04 at 14:41 +0200, Klaus D. Witzel wrote:
On Wed, 04 Jun 2008 12:12:59 +0200, Bert Freudenberg wrote:
On 04.06.2008, at 10:32, Klaus D. Witzel wrote:
On Wed, 04 Jun 2008 09:55:11 +0200, Norbert Hartl wrote:
The objects are still referenced in the collection you get from self selected. The line with "each := nil" is useless as each is only a temporary variable.
Not 100% useless, since temporary variables (and arguments, for that matter) survive any attempt, from within the same method, to garbage collect them:
{'this ', 'and ', 'that'} collect: [:each | ]. Smalltalk garbageCollect. {thisContext tempAt: 1} inspect
first line: create some object and make a temp var point to it. second line: invoke GC. third line: see what's still pointed to by the temp var.
Yikes. Klaus, please keep the hair-splitting to squeak-dev if possible.
Ah. Didn't know that enumerating+removing with a block with argument
- GC'ing in the same method, belongs to hair-splitting. Instead, I always
thought that's one of the reasons that at least one to-be-removed object is guaranteed to not go away.
But anyways, thanks for letting me know ;)
I don't care if it is called hair-splitting or something different. I must agree with Bert. I found it interesting but misplaced on beginners. What you were talking about had nothing to do with the Problem Rob was asking (and to continue in Bert's words: If you use thisContext tempAt: you've left the beginner area already). With your first line you confused even me and I'm little bit reluctant now to be called a newbie ;)
Writing
{ 'this', 'and', 'that' }
instead of
Array with: 'this and that'
let people like me assume there is some black magic happening. To under- stand the problem dots instead of commata makes it clearer. So maybe you can understand that while you are right you can spread uncertainty to those which aren't that experienced (this includes me as well). And to some who are that experienced it appears like hair-splitting ;)
Norbert
Assigning to a block parameter is just wrong.
You better read before you write (the way you most often do indeed ;) then you'd find that I didn't write any assignment to anything. Instead, I ignored that and pointed to a potential beginner's problem. Sorry you didn't like that ;)
Setting temps to nil is unnecessary in any normal method. If your code actually needs to worry about this, then you left the beginner playground.
And if he does removal+GC+check for success in the same method? I cannot see whether someone just copies arbitrary statements given in a response to a question, or carefully puts them into separate methods, in his code in his .image, now or never ;)
Rob: Here's a recipe to find out what is keeping your instances from being garbage-collected:
http://wiki.squeak.org/squeak/2631
- Bert -
Beginners mailing list Beginners@lists.squeakfoundation.org http://lists.squeakfoundation.org/mailman/listinfo/beginners
On Thu, Jun 5, 2008 at 8:02 AM, Norbert Hartl norbert@hartl.name wrote:
I don't care if it is called hair-splitting or something different. I must agree with Bert. I found it interesting but misplaced on beginners. What you were talking about had nothing to do with the Problem Rob was asking (and to continue in Bert's words: If you use thisContext tempAt: you've left the beginner area already). With your first line you confused even me and I'm little bit reluctant now to be called a newbie ;)
Writing
{ 'this', 'and', 'that' }
instead of
Array with: 'this and that'
let people like me assume there is some black magic happening. To under- stand the problem dots instead of commata makes it clearer. So maybe you can understand that while you are right you can spread uncertainty to those which aren't that experienced (this includes me as well). And to some who are that experienced it appears like hair-splitting ;)
Nonetheless, thanks to all your help, I understand things better now, and can properly remove objects I currently "have control over." Because I was able to test things based on all your feedback, I have narrowed my problem down to an Aida misunderstanding on my part.
For any Aida-ers out there, playing with a WebGrid, it's bound objects, and garbage collection should lead one to a greater understanding of WebSession(s) and WebSessionManager(s)! I'm not saying I've figured it out yet--just that I can get reproducible results now!
Thanks for the help,
Rob
Rob Rothwell wrote:
Nonetheless, thanks to all your help, I understand things better now, and can properly remove objects I currently "have control over." Because I was able to test things based on all your feedback, I have narrowed my problem down to an Aida misunderstanding on my part.
For any Aida-ers out there, playing with a WebGrid, it's bound objects, and garbage collection should lead one to a greater understanding of WebSession(s) and WebSessionManager(s)! I'm not saying I've figured it out yet--just that I can get reproducible results now!
Yes, WebGrid (kind of smart web table) caches presented objects in session presentation state (instances of your Apps, that is subclasses of WebApplication) until you clean up that state. Because Aida web apps don't have a session timeout by default, this cleanup is done explicitly, usually every night.
But let we move this discussion back to Aida mailing list. Others can follow or join it here: http://www.aidaweb.si/community.html
Best regards Janko
On Wed, 2008-06-04 at 10:32 +0200, Klaus D. Witzel wrote:
On Wed, 04 Jun 2008 09:55:11 +0200, Norbert Hartl wrote:
On Wed, 2008-06-04 at 00:04 -0400, Rob Rothwell wrote:
Hello,
After much help already, I think I need some training in proper object removal.
When my application creates an object and stores it in an OrderedCollection, and than wants to delete it, I am trying to do so quite explicitly with something like:
DataManager>>deleteSelectedAbstractors self selected do: [:each | self abstractors remove: each. each := nil. ]
which removes the object from my application (it's collection), and yet when I look for my object in the system with
DataAbstractor allInstances.
I still see the object I removed, even with an explicit Smalltalk garbageCollect or garbageCollectMost. Anything I create just seems to hang around forever.
Any help understanding what I need to do to make sure my objects really go away when I am done with them would be greatly appreciated!
The objects are still referenced in the collection you get from self selected. The line with "each := nil" is useless as each is only a temporary variable.
Not 100% useless, since temporary variables (and arguments, for that matter) survive any attempt, from within the same method, to garbage collect them:
{'this ', 'and ', 'that'} collect: [:each | ]. Smalltalk garbageCollect. {thisContext tempAt: 1} inspect
first line: create some object and make a temp var point to it. second line: invoke GC. third line: see what's still pointed to by the temp var.
Ok, you confused me completely. I was baffled getting a bytestring containing 'this and that'. Shortly after I recognized the commata in your Array assignment. I think you meant
{'this'. 'and'. 'that}
Isn't this an issue of BlockContext? Through a similar effect I used to learn fixTemps. Would this be the same behaviour using full closures?
Norbert
/Klaus
I assume that you want to empty the selected collection as well. you could do
DataManager>>deleteSelectedAbstractors self selected copy do: [:each | self abstractors remove: each. self selected remove: each. ]
regards,
Norbert
Beginners mailing list Beginners@lists.squeakfoundation.org http://lists.squeakfoundation.org/mailman/listinfo/beginners
On Wed, 04 Jun 2008 19:09:17 +0200, Norbert Hartl wrote:
On Wed, 2008-06-04 at 10:32 +0200, Klaus D. Witzel wrote:
On Wed, 04 Jun 2008 09:55:11 +0200, Norbert Hartl wrote:
On Wed, 2008-06-04 at 00:04 -0400, Rob Rothwell wrote:
Hello,
After much help already, I think I need some training in proper
object
removal.
When my application creates an object and stores it in an OrderedCollection, and than wants to delete it, I am trying to do so quite explicitly with something like:
DataManager>>deleteSelectedAbstractors self selected do: [:each | self abstractors remove: each. each := nil. ]
which removes the object from my application (it's collection), and yet when I look for my object in the system with
DataAbstractor allInstances.
I still see the object I removed, even with an explicit Smalltalk garbageCollect or garbageCollectMost. Anything I create just seems
to
hang around forever.
Any help understanding what I need to do to make sure my objects really go away when I am done with them would be greatly appreciated!
The objects are still referenced in the collection you get from self selected. The line with "each := nil" is useless as each is only a temporary variable.
Not 100% useless, since temporary variables (and arguments, for that matter) survive any attempt, from within the same method, to garbage collect them:
{'this ', 'and ', 'that'} collect: [:each | ]. Smalltalk garbageCollect. {thisContext tempAt: 1} inspect
first line: create some object and make a temp var point to it. second line: invoke GC. third line: see what's still pointed to by the temp var.
Ok, you confused me completely. I was baffled getting a bytestring containing 'this and that'. Shortly after I recognized the commata in your Array assignment. I think you meant
{'this'. 'and'. 'that}
Oh :) I didn't think about commata or periods; why not: both serve the example equally well, a *nonempty* collection expressed with {} ;)
Isn't this an issue of BlockContext?
Yes, and it could be avoided by, as indicated earlier, separating the removal-part (and its block with argument) from the GC+check part (putting both parts in their own method).
Through a similar effect I used to learn fixTemps. Would this be the same behaviour using full closures?
Right, full block closures are supposed go away at GC time (incl. their args and temps) when no longer referenced (as is in the example).
Norbert
/Klaus
I assume that you want to empty the selected collection as well. you could do
DataManager>>deleteSelectedAbstractors self selected copy do: [:each | self abstractors remove: each. self selected remove: each. ]
regards,
Norbert
Beginners mailing list Beginners@lists.squeakfoundation.org http://lists.squeakfoundation.org/mailman/listinfo/beginners
On Wed, Jun 4, 2008 at 3:55 AM, Norbert Hartl norbert@hartl.name wrote:
The objects are still referenced in the collection you get from self selected. The line with "each := nil" is useless as each is only a temporary variable. I assume that you want to empty the selected collection as well. you could do
DataManager>>deleteSelectedAbstractors self selected copy do: [:each | self abstractors remove: each. self selected remove: each. ]
So...why would I use a copy (self selected copy) in this case? Is that a clue to my misunderstanding?
Rob
2008/6/4 Rob Rothwell r.j.rothwell@gmail.com:
On Wed, Jun 4, 2008 at 3:55 AM, Norbert Hartl norbert@hartl.name wrote:
Hi
The objects are still referenced in the collection you get from self selected. The line with "each := nil" is useless as each is only a temporary variable. I assume that you want to empty the selected collection as well. you could do
DataManager>>deleteSelectedAbstractors self selected copy do: [:each | self abstractors remove: each. self selected remove: each. ]
So...why would I use a copy (self selected copy) in this case? Is that a clue to my misunderstanding?
Rob
because
self selected do: [:each | self selected remove: each ] is to avoid ... as it iterates on the collection on wich you're removing elements...
Try
aColl:=#(1 2 3) asOrderedCollection. ^aColl do: [:ea | aColl remove ea ]
see here: http://bugs.squeak.org/view.php?id=6937
Cédrick
Rob Rothwell-2 wrote:
[snip]
DataManager>>deleteSelectedAbstractors self selected copy do: [:each | self abstractors remove: each. self selected remove: each. ]
So...why would I use a copy (self selected copy) in this case? Is that a clue to my misunderstanding?
Because the copy of the collection will live only during the execution of #do: and thus it won't hang on to references to your objects.
Saludos,
Victor Rodriguez.
Rob
Beginners mailing list Beginners@lists.squeakfoundation.org http://lists.squeakfoundation.org/mailman/listinfo/beginners
beginners@lists.squeakfoundation.org
-
Bert Freudenberg -
cdrick -
Herbert König -
Janko Mivšek -
Klaus D. Witzel -
Norbert Hartl -
Rob Rothwell -
Victor Rodriguez