[Pharo-project] [Nautilus] Someone needs to learn how to work with weak references :) + [Enh] patch to object explorer
my work image grown to 80Mb in size.. and i start growing suspicious about myself for forming a resource leak somewhere.. But as it appears, it is because of Nautilus. During my experiments with ObjC wrapper for NativeBoost, i used nautilus for showing more than 4000 Objective-C classes in browser.. Since all those objects are actually wrappers, they generated each time when i open a new browser window.. to explore an obj-c universe and to test bugs.. So i ended up with: ObjCClassWrapper allInstances size 31885 Now, about why cache doesn't cleaning up automatically: The only reference coming to particular instance of ObjC wrapper is from a ClassesIconCache class var, which is a weak key dictionary: {my class wrapper} -> [IconicButtonStateHolder] so, a {wrapper} is held weakly here, of course, while [its Icon] strongly, and so far so good. But the problem is that , [IconicButtonStateHolder] having following in it's arguments ivar: an Array(an ObjCClassWrapper), which is [my class wrapper], held strongly. of course, there is no way how it can disappear from system.. After doing "AbstractNautilusUI resetIconCaches" my image shrunk from 83Mb down to 43Mb, But i found that i still having a lot of ObjCClassWrapper hanging around and wonder why.. And this time, because one of the wrapper classes were held in HistoryCollection via Nautilus 'RecentClasses' classvar. I think, history should not keep a live object references.. but instead use symbolic names to refer to the target, because apparently you cannot go and browse the method/class if you deleted it from a system. So, after nilling out that class var, my image lost another 10Mb, down to 33Mb.. and Ben, you owe me a ... (o shit i don't drink beer ) oh ok.. you owe me 2 bug fixes in Nautilus :) P.S. i modified a pointer explorer to show only strong references to object(s), because weak ones are completely useless for fighting with resource leak problems and only add noise. With this change a lists produced by pointer explorer are much shorter and going straight to the point. So, i attaching .cs to the mail.. in case if someone find it useful. -- Best regards, Igor Stasenko.
p.p.p.s. perhaps we could add it as option "explore only strong references" in inspector menu -- Best regards, Igor Stasenko.
Igor add a bug entry and your code so that we add this menu On Sep 2, 2012, at 3:41 AM, Igor Stasenko wrote:
p.p.p.s. perhaps we could add it as option "explore only strong references" in inspector menu
-- Best regards, Igor Stasenko.
On 2 September 2012 10:16, Stéphane Ducasse <stephane.ducasse@inria.fr> wrote:
Igor add a bug entry and your code so that we add this menu
http://code.google.com/p/cog/issues/detail?id=95
On Sep 2, 2012, at 3:41 AM, Igor Stasenko wrote:
p.p.p.s. perhaps we could add it as option "explore only strong references" in inspector menu
-- Best regards, Igor Stasenko.
-- Best regards, Igor Stasenko.
2 digits are missing in the url I guess Ben On Sep 2, 2012, at 5:15 PM, Igor Stasenko wrote:
On 2 September 2012 10:16, Stéphane Ducasse <stephane.ducasse@inria.fr> wrote:
Igor add a bug entry and your code so that we add this menu
http://code.google.com/p/cog/issues/detail?id=95
On Sep 2, 2012, at 3:41 AM, Igor Stasenko wrote:
p.p.p.s. perhaps we could add it as option "explore only strong references" in inspector menu
-- Best regards, Igor Stasenko.
-- Best regards, Igor Stasenko.
On 2 September 2012 17:31, Benjamin <benjamin.vanryseghem.pharo@gmail.com> wrote:
2 digits are missing in the url I guess
no, i was mistakenly posted to cog issue tracker. use this instead: http://code.google.com/p/pharo/issues/detail?id=6630
Ben
On Sep 2, 2012, at 5:15 PM, Igor Stasenko wrote:
On 2 September 2012 10:16, Stéphane Ducasse <stephane.ducasse@inria.fr> wrote:
Igor add a bug entry and your code so that we add this menu
http://code.google.com/p/cog/issues/detail?id=95
On Sep 2, 2012, at 3:41 AM, Igor Stasenko wrote:
p.p.p.s. perhaps we could add it as option "explore only strong references" in inspector menu
-- Best regards, Igor Stasenko.
-- Best regards, Igor Stasenko.
-- Best regards, Igor Stasenko.
oops , posted into wrong issue tracker http://code.google.com/p/pharo/issues/detail?id=6630 -- Best regards, Igor Stasenko.
Igor, have you been following Craig Latta's work with Naev/Spoon? He's had to create some very interesting tools to track objects of various kinds in the image. L On 9/1/12 6:31 PM, Igor Stasenko wrote:
my work image grown to 80Mb in size.. and i start growing suspicious about myself for forming a resource leak somewhere..
But as it appears, it is because of Nautilus.
During my experiments with ObjC wrapper for NativeBoost, i used nautilus for showing more than 4000 Objective-C classes in browser..
Since all those objects are actually wrappers, they generated each time when i open a new browser window.. to explore an obj-c universe and to test bugs.. So i ended up with: ObjCClassWrapper allInstances size 31885
Now, about why cache doesn't cleaning up automatically:
The only reference coming to particular instance of ObjC wrapper is from a ClassesIconCache class var, which is a weak key dictionary:
{my class wrapper} -> [IconicButtonStateHolder]
so, a {wrapper} is held weakly here, of course, while [its Icon] strongly, and so far so good.
But the problem is that , [IconicButtonStateHolder] having following in it's arguments ivar:
an Array(an ObjCClassWrapper), which is [my class wrapper], held strongly.
of course, there is no way how it can disappear from system..
After doing "AbstractNautilusUI resetIconCaches" my image shrunk from 83Mb down to 43Mb,
But i found that i still having a lot of ObjCClassWrapper hanging around and wonder why.. And this time, because one of the wrapper classes were held in HistoryCollection via Nautilus 'RecentClasses' classvar. I think, history should not keep a live object references.. but instead use symbolic names to refer to the target, because apparently you cannot go and browse the method/class if you deleted it from a system.
So, after nilling out that class var, my image lost another 10Mb, down to 33Mb.. and Ben, you owe me a ... (o shit i don't drink beer ) oh ok.. you owe me 2 bug fixes in Nautilus :)
P.S. i modified a pointer explorer to show only strong references to object(s), because weak ones are completely useless for fighting with resource leak problems and only add noise. With this change a lists produced by pointer explorer are much shorter and going straight to the point. So, i attaching .cs to the mail.. in case if someone find it useful.
-- Squeak from the very start (introduction to Squeak and Pharo Smalltalk for the (almost) complete and compleate beginner). https://www.youtube.com/playlist?list=PL6601A198DF14788D&feature=view_all
On 2 September 2012 06:00, Lawson English <lenglish5@cox.net> wrote:
Igor, have you been following Craig Latta's work with Naev/Spoon?
He's had to create some very interesting tools to track objects of various kinds in the image.
Well, Spoon was one of the first things i learned besides squeak. I know Craig has some visualizations done for looking at object memory using human's eyes.. but without ways to filter out the noise (which requires some coding), any visualization is basically useless, because of the amount of information.
L
On 9/1/12 6:31 PM, Igor Stasenko wrote:
my work image grown to 80Mb in size.. and i start growing suspicious about myself for forming a resource leak somewhere..
But as it appears, it is because of Nautilus.
During my experiments with ObjC wrapper for NativeBoost, i used nautilus for showing more than 4000 Objective-C classes in browser..
Since all those objects are actually wrappers, they generated each time when i open a new browser window.. to explore an obj-c universe and to test bugs.. So i ended up with: ObjCClassWrapper allInstances size 31885
Now, about why cache doesn't cleaning up automatically:
The only reference coming to particular instance of ObjC wrapper is from a ClassesIconCache class var, which is a weak key dictionary:
{my class wrapper} -> [IconicButtonStateHolder]
so, a {wrapper} is held weakly here, of course, while [its Icon] strongly, and so far so good.
But the problem is that , [IconicButtonStateHolder] having following in it's arguments ivar:
an Array(an ObjCClassWrapper), which is [my class wrapper], held strongly.
of course, there is no way how it can disappear from system..
After doing "AbstractNautilusUI resetIconCaches" my image shrunk from 83Mb down to 43Mb,
But i found that i still having a lot of ObjCClassWrapper hanging around and wonder why.. And this time, because one of the wrapper classes were held in HistoryCollection via Nautilus 'RecentClasses' classvar. I think, history should not keep a live object references.. but instead use symbolic names to refer to the target, because apparently you cannot go and browse the method/class if you deleted it from a system.
So, after nilling out that class var, my image lost another 10Mb, down to 33Mb.. and Ben, you owe me a ... (o shit i don't drink beer ) oh ok.. you owe me 2 bug fixes in Nautilus :)
P.S. i modified a pointer explorer to show only strong references to object(s), because weak ones are completely useless for fighting with resource leak problems and only add noise. With this change a lists produced by pointer explorer are much shorter and going straight to the point. So, i attaching .cs to the mail.. in case if someone find it useful.
-- Squeak from the very start (introduction to Squeak and Pharo Smalltalk for the (almost) complete and compleate beginner). https://www.youtube.com/playlist?list=PL6601A198DF14788D&feature=view_all
-- Best regards, Igor Stasenko.
Actually, speaking about the problem of locating memory leaks, by filtering out useless stuff, it looks like quite simple to implement: you just need to trace path(s) from system root (such as Smalltalk global object) to the object of interest. A shortest path found, in most cases, will be the answer to problem. -- Best regards, Igor Stasenko.
participants (4)
-
Benjamin -
Igor Stasenko -
Lawson English -
Stéphane Ducasse