help-smalltalk
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [Help-smalltalk] Strategy to finding memleaks


From: Paolo Bonzini
Subject: Re: [Help-smalltalk] Strategy to finding memleaks
Date: Sat, 09 Apr 2011 10:24:03 +0200
User-agent: Mozilla/5.0 (X11; U; Linux x86_64; en-US; rv:1.9.2.13) Gecko/20101209 Fedora/3.1.7-0.35.b3pre.fc14 Lightning/1.0b3pre Mnenhy/0.8.3 Thunderbird/3.1.7

On 04/09/2011 09:55 AM, Holger Hans Peter Freyther wrote:
Hi Paolo,

my postgres code is now working like it should and to test it I was letting it
run in a loop and I see that there is an increase in usage of memory. My first
try was to use ObjectMemory to force a global garbage collect but that did not
change anything, I will try with compacting heaps now as well.

Do you have any strategy to find memory leaks? How is this Eden working? If an
Object is moved there it will never be GCed?

No, absolutely not! Objects are always GCed. Eden is where objects are _born_, and until they are in the eden reclaiming them is particularly efficient.

To find memory leaks, I suggest you use instanceCount and find objects with a very large number of instances. From there, finding the owners (which may not have a very large number of instances, but are the roots of the leak) is usually easy. Possibly you can do something like

    x := SomeClass someInstance.
    [o := x allOwners. o isEmpty] whileTrue: [ x := x nextInstance ].
    (o collect: [ :each |each class]) asBag

and recurse on the classes shown in the bag.

Usually, saving the image and doing the above in the REPL will also be useful to find leaks.

I believe the archives have some information on finding leaks related to Iliad (July 2009, should be).

Paolo



reply via email to

[Prev in Thread] Current Thread [Next in Thread]