GC limitations?

Previous Topic Next Topic
 
classic Classic list List threaded Threaded
3 messages Options
Reply | Threaded
Open this post in threaded view
|

GC limitations?

Schwab,Wilhelm K
Hello all,

I have a weird-looking bug that I am willing to assume is my doing and in my code.  That said, some debugging lead me to a situation I really do not enjoy: objects that I think should be gc'd are happily living in my image.  I _think_ I have gagged workspace variables (they truly are more trouble than they are worth).  Dolphin sometimes has "zombie" views that can lurk in a broken/invisible state but still hold onto other objects.  Is there anything like that here?  I know about the various #become: tricks, and do not like to resort to them; I would like to understand what is holding onto the would-be garbage.

Can the Squeak/Pharo gc collect objects with cyclic references?  Is there anything else comes to mind when hunting for objects that just won't go away?

Bill


_______________________________________________
Pharo-project mailing list
[hidden email]
http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
Reply | Threaded
Open this post in threaded view
|

Re: GC limitations?

Miguel Cobá
El mar, 21-07-2009 a las 01:13 -0400, Schwab,Wilhelm K escribió:
> Hello all,
>
> I have a weird-looking bug that I am willing to assume is my doing and in my code.  That said, some debugging lead me to a situation I really do not enjoy: objects that I think should be gc'd are happily living in my image.  I _think_ I have gagged workspace variables (they truly are more trouble than they are worth).  Dolphin sometimes has "zombie" views that can lurk in a broken/invisible state but still hold onto other objects.  Is there anything like that here?  I know about the various #become: tricks, and do not like to resort to them; I would like to understand what is holding onto the would-be garbage.
>
> Can the Squeak/Pharo gc collect objects with cyclic references?  Is there anything else comes to mind when hunting for objects that just won't go away?
>
> Bill

Use the pointer finder, either from a debug window where you can see a
variable that you think should not exist, search the context menu for
"Chase pointers" or "explore pointers" or directly by using
PointerFinder. From the class comment:

I can search for reasons why a certain object isn't garbage collected.
I'm a quick port of a VisualWorks program written by Hans-Martin Mosner.
Call me as shown below.  I'll search for a path from a global variable
to the given object, presenting it in a small morphic UI.

Examples:
        PointerFinder on: self currentHand
        PointerFinder on: StandardSystemView someInstance

Now, let's see why this image contains more HandMorphs as expected...

HandMorph allInstancesDo: [:e | PointerFinder on: e]

Miguel Cobá
>
>
> _______________________________________________
> Pharo-project mailing list
> [hidden email]
> http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project


_______________________________________________
Pharo-project mailing list
[hidden email]
http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
Reply | Threaded
Open this post in threaded view
|

Re: GC limitations?

Schwab,Wilhelm K
Miguel,

I stumbled into PointerFinder and the menu commands (why both chase and explore?), so far without helpful results.  It was late though, so I'll give it another try.  Thanks!

Bill


-----Original Message-----
From: [hidden email] [mailto:[hidden email]] On Behalf Of Miguel Enrique Cobá Martinez
Sent: Tuesday, July 21, 2009 12:34 AM
To: [hidden email]
Subject: Re: [Pharo-project] GC limitations?

El mar, 21-07-2009 a las 01:13 -0400, Schwab,Wilhelm K escribió:
> Hello all,
>
> I have a weird-looking bug that I am willing to assume is my doing and in my code.  That said, some debugging lead me to a situation I really do not enjoy: objects that I think should be gc'd are happily living in my image.  I _think_ I have gagged workspace variables (they truly are more trouble than they are worth).  Dolphin sometimes has "zombie" views that can lurk in a broken/invisible state but still hold onto other objects.  Is there anything like that here?  I know about the various #become: tricks, and do not like to resort to them; I would like to understand what is holding onto the would-be garbage.
>
> Can the Squeak/Pharo gc collect objects with cyclic references?  Is there anything else comes to mind when hunting for objects that just won't go away?
>
> Bill

Use the pointer finder, either from a debug window where you can see a variable that you think should not exist, search the context menu for "Chase pointers" or "explore pointers" or directly by using PointerFinder. From the class comment:

I can search for reasons why a certain object isn't garbage collected.
I'm a quick port of a VisualWorks program written by Hans-Martin Mosner.
Call me as shown below.  I'll search for a path from a global variable to the given object, presenting it in a small morphic UI.

Examples:
        PointerFinder on: self currentHand
        PointerFinder on: StandardSystemView someInstance

Now, let's see why this image contains more HandMorphs as expected...

HandMorph allInstancesDo: [:e | PointerFinder on: e]

Miguel Cobá
>
>
> _______________________________________________
> Pharo-project mailing list
> [hidden email]
> http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project


_______________________________________________
Pharo-project mailing list
[hidden email]
http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
_______________________________________________
Pharo-project mailing list
[hidden email]
http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project