On 01/31/2017 06:45 AM, stepharong wrote:
thierry
we have pointersTo and I imagine that it is not good enough.
Do you confirm?
#pointersTo appears to be the same as #allReferences and #allOwners in
other Smalltalk implementations. These methods are terrible for finding
the reason for the memory leak. To find the root of the problem, you
start with some object you think should have been GCed. The #pointersTo
gives you which objects reference that object. Then you iterate picking
some object in the previous pointersTo list and asking for its
pointersTo until you get to the class variable or class instance
variable that is the real root of the problem. The difficulty with this
process is "picking some object" from the pointersTo list to do another
pointersTo. You may pick an object that is part of the inspectors that
you are using. Another common problem is picking an object that you have
already seen (cycles). I don't know about the Pharo implementation, but
some of the other implementations also have a problem of having
implementation objects showing in the pointersTo list (i.e., objects
that were created by the pointersTo process).
As for the ease of use, I have an image where I just closed my work
window, and see that I still have some PBVariableNodes laying around. If
I execute "PBVariableNode allInstances first pointersTo" I get an array
with 2 items. The first is an array with 4 items and the second is an
array with 11587 items. Now, I would need to pick which of these I would
need to do pointersTo.
If I use my ReferenceFinder, I can do "ReferenceFinder findPathTo:
PBVariableNode allInstances first" or even "ReferenceFinder
findPathToInstanceOf: PBVariableNode". This will give me an array where
the first object is the Smalltalk system dictionary and the last object
is a PBVariableNode. In my case, I see a reference path goes through the
ASTCache. That object is holding on, somewhat indirectly, to my
anonymous class that is no longer being held by anything else.
Therefore, I concluded that either the ASTCache needs to be changed so
that it no longer caches items for anonymous classes, or I need to
change my code to remove all methods from the anonymous class before
exiting (since the ASTCache uses a weak key cache on the compiled method).
BTW, the reference path also shows that it would have been wise to pick
the array of 11587 items to do the pointersTo analysis on above.
John Brant
