continuum-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Brett Porter <>
Subject memory leak investigations
Date Thu, 13 Apr 2006 06:22:39 GMT

I've done some investigation.

I was able to run the server where it was just checking for non-existant 
updates for some time, and it had no net result on memory usage (it 
constantly goes up, gc's back to the same level, etc).

When I ran a "build all" on cheddar (with no checkouts), net memory 
usage increased 40Mb to build all 130-odd projects (it was at 24mb, now 
it idles at 62 - it was around 80 but 20mb went away after GC). Now, it 
idles at the same level again (even after enqueuing all again, but not 

I took a snapshot at the start and end, and there is 38mb in a single 
hashmap with 513 elements. This map is the 
componentManagersByComponentHashCode field of 
DefaultComponentManagerManager. This would have to be unreleased 
components, right?

Some more things high in the allocation count:
- SecureRunData has 2mb that wasn't there before. It is a possible 
suspect since it is new in 1.0.3. It occurs more than once.
- ContinuumStateContentGenerator has 2mb. Another possible suspect for 
an unreleased component. There are 3 of them in the top 20.
- The second most allocated is a hasmap in the projectBuilder 
(processedProjectCache), at 5mb. This may just be acceptable use.
- DefaultViewContext has much as well, but I think that's because it 
stores all the state generators

The rest seem to be more instances of the above 4.

I don't have more time to investigate - I'd suggest perhaps logging all 
components released when the container shuts down, and just build one 
project from scratch to see what components are left in there at the end..

So it seems the actual specs we need:
- 20mb baseline
- 20mb buffer to build
- caches (eg projects)

It should easily fit in 64mb, with 128mb being safe if we are to spec 
out requirements.


View raw message