How to pinpoint memory leaks 
Author Message
 How to pinpoint memory leaks

Hi all,

I will soon have to solve a problem concerning memory leak for one of
our clients.

The application contains some 250 classes and is gemstone connected, the
client memory usage grows prohibitivly during a normal day's work.

Are there any tools available to do the first step of counting instances
of all application classes in a (not-too-)brute-force way.

I have been trying to enumerate all of the classes involved and keeping
track of changes in instance counts, but it is just waaayyy to slow to
be usefull (probably because Behavior>>allInstances does garbage
collection).

Also I've been playing with the 'visualization' tool that come with the
distributed option, but 250 classes is just too much info to use in it's
browser, it will only become helpfull after I found the first hints as
to where the problem lies and can cut down on the classes monitored.
Also if it is not a application class that is using the memory I may
have to monitor system classes too :-(

So does anybody know of tools or simple tricks to pinpoint excessive
instance count growth among a large number of classes?

VAST ver 4.02

cc to my email appreciated,
TIA!

Reinout Heeck
-------------



Wed, 18 Jun 1902 08:00:00 GMT  
 How to pinpoint memory leaks
A couple of things:

Quote:
> The application contains some 250 classes and is gemstone connected,
the
> client memory usage grows prohibitivly during a normal day's work.

Have you checked Dependents (I think that's what it's called in VA)?

Quote:
> Are there any tools available to do the first step of counting
instances
> of all application classes in a (not-too-)brute-force way.

> I have been trying to enumerate all of the classes involved and
keeping
> track of changes in instance counts, but it is just waaayyy to slow to
> be usefull (probably because Behavior>>allInstances does garbage
> collection).

I believe you can just invoke allInstancesPrim or basicAllInstances
(I've been away from VA for over a year, and I've forgotten quite a
few method names).  It's still dead slow, of course, but at least
that terribly inefficient garbage collector won't be invoked.

Quote:
> browser, it will only become helpfull after I found the first hints as
> to where the problem lies and can cut down on the classes monitored.

Hm, tough problem.  You might want to try something a little
counter-intuitive: Start with "Array allInstances".  Put these
into a WeakArray (AbtWeakArray or something?), run the application
for a while, then compute "Array allInstances" again.  Subtract
the first ones from the second ones, and you'll have all Arrays
that were constructed since the first run.  Since Arrays get used
in all sorts of things (I believe VA even uses them inside
OrderedCollections), you might be able to glean some information
from these new Arrays.  Scan them mechanically (one level deep only)
to compute an estimated number of instances for each class in the
image.  That statistic should have a *lot* of noise in it, but it
should help you locate a starting point for your search (you may
want to sort by descending number of instances found).

Quote:
> Also if it is not a application class that is using the memory I may
> have to monitor system classes too :-(

> So does anybody know of tools or simple tricks to pinpoint excessive
> instance count growth among a large number of classes?

In VW I can just execute "ObjectMemory allObjects" and get back an
Array containing every object in the image (it takes about a second
on a 450MHz machine containing 582460 objects).  I can compute the
instance counts from this, run some code, then compute
"ObjectMemory allObjects" again, subtract the statistics, and know
exactly how many of each kind of object was created but not
destroyed.  Even better, I know exactly what the change in instance
count is, not the number of "new" objects, so replacements (e.g.,
during collection growth, window opening/closing, etc) are
automatically subtracted from the statistics.  But that's VW only.

I do seem to recall a multiAllInstances or some such from VA - if
that's not my imagination, that would help a lot.

Good luck!

Sent via Deja.com http://www.deja.com/
Share what you know. Learn what you don't.



Wed, 18 Jun 1902 08:00:00 GMT  
 How to pinpoint memory leaks
Quote:

> A couple of things:

[...]

I'll try my luck with this,

Thanx!

Reinout Heeck
-------------



Wed, 18 Jun 1902 08:00:00 GMT  
 How to pinpoint memory leaks

Quote:

>Hi all,

>I will soon have to solve a problem concerning memory leak for one of
>our clients.

>The application contains some 250 classes and is gemstone connected, the
>client memory usage grows prohibitivly during a normal day's work.

>Are there any tools available to do the first step of counting instances
>of all application classes in a (not-too-)brute-force way.

The ENVY/Stats tools had some tools for profiling memory usage which sound
roughly like what you need.

--

The Object People               613.225.8812(v)   613.225.5943(f)    



Wed, 18 Jun 1902 08:00:00 GMT  
 How to pinpoint memory leaks
Reinout,

 If you suspect you have leaking Object subclass instances (as opposed to
AbtObservableObject) and these are involved in dependencies (via visual
programming or through use of abtWhen:perform:) then look at the class
variable in the AbtCLDTAdditions class (I believe it is called
AbtEventDependents). This weak key identity dictionary holds on to the
VisualAge relevent dependencies. If you have closed down all your windows
and as far as you understand it, all dependencies should have been freed but
you still have some customer objects in there, then you have a leak.
One of the activities done by "System abtScrubImage" is to clean out this
dictionary.  In fact, you may find that very message to be a good starting
point.

These kind of problems often occur because of circular refs or dependencies
which cannot be cleaned out automagically by the weak key dictionary. If it
is an option for packaging, subclassing off of AbtObservableObject instead
of Object has often fixed these kind of problems. Reason for this is that
AbtObservableObjects  hold on to their own event dependents. As a part of
programming practice, coding explicit dependency releases can also allow you
to keep control - especially so when dependents are registered "manually".

Ron Charron
The Object People
visit http://www.objectpeople.com/Smalltalkchronicles.htm/


Quote:
> Hi all,

> I will soon have to solve a problem concerning memory leak for one of
> our clients.

> The application contains some 250 classes and is gemstone connected, the
> client memory usage grows prohibitivly during a normal day's work.

> Are there any tools available to do the first step of counting instances
> of all application classes in a (not-too-)brute-force way.

> I have been trying to enumerate all of the classes involved and keeping
> track of changes in instance counts, but it is just waaayyy to slow to
> be usefull (probably because Behavior>>allInstances does garbage
> collection).

> Also I've been playing with the 'visualization' tool that come with the
> distributed option, but 250 classes is just too much info to use in it's
> browser, it will only become helpfull after I found the first hints as
> to where the problem lies and can cut down on the classes monitored.
> Also if it is not a application class that is using the memory I may
> have to monitor system classes too :-(

> So does anybody know of tools or simple tricks to pinpoint excessive
> instance count growth among a large number of classes?

> VAST ver 4.02

> cc to my email appreciated,
> TIA!

> Reinout Heeck
> -------------




Wed, 18 Jun 1902 08:00:00 GMT  
 How to pinpoint memory leaks

Quote:
> Hi all,

> I will soon have to solve a problem concerning memory leak for one of
> our clients.

> The application contains some 250 classes and is gemstone connected, the
> client memory usage grows prohibitivly during a normal day's work.

> Are there any tools available to do the first step of counting instances
> of all application classes in a (not-too-)brute-force way.

> ...

If you need only a count of instances, not the reference to them, there is a
much faster way than >>allInstances Set up an Array wich contains all classes
you are interested in and execute:  myArray>>countInstances

(This method comes with App EsMemoryUsage in VA4.5, I'm not sure but VA4.02
may contain it in an other EsMem* Application )

The method returns an Array of same size and contains for each class an Array
with count of instances and occupied size.

You can do it for specific classes up to ' System allClasses asArray ' within
splitSecond time.

Have fun
Martin

Sent via Deja.com http://www.deja.com/
Share what you know. Learn what you don't.



Wed, 18 Jun 1902 08:00:00 GMT  
 
 [ 6 post ] 

 Relevant Pages 

1. memory leak and leak-fixing 'patterns'

2. python startup memory size and memory leak

3. Uninitialized memory errors and memory leaks in Tk

4. memory usage (how to debug a memory leak?)

5. Possible Dolphi R4 memory leak using ODBC

6. GETDSAB and memory leaks

7. TopLink errors and memory leaks

8. memory leak in gawk 3.1.0 ?

9. ENFIN Memory Leak

10. Memory Leaks

11. Memory Leaks in OS X?

12. Memory Leaks on OS X

 

 
Powered by phpBB® Forum Software