On Sun, 27 Aug 2006 ara.t.howard / noaa.gov wrote:

> but it doesn't show a leak on my system, on bob's system, or on ed's system?
> just tons of memory usage.  are you ignoring the fact that no one else who 
> has
> run it shows a leak either?  how about the fact that electric fence, mpatrol,
> and mtrace also show no leak?  how about the fact that very few people have
> had issues with mutex and memory?

I have been playing with this all morning.

I added a line to the script to print the object count when it prints how 
many threads are still spinning:

oc = 0; ObjectSpace.each_object {oc += 1}; STDERR.puts "OC: #{oc}"

And I changed it so that it creates a specific number of threads, like 
other people have, and I played both with keeping the explicit GC.start 
and removing it.

I altered the array creation line in the thread to use memory faster:

30000.times {|i| ta << "#{i}" }

Making a string out of that number is a much hungrier operation that, much 
more quickly, seems to show Mutex "leaking".

Finally, I added a three second sleep between when one set of 1000 threads 
finishes and when the next is started.

Other than that, I left it alone.

One version of the code I have been using is here:

http://rafb.net/paste/results/NbwVMo51.html

Then I sat here and ran the Mutex version and the Sync version over and 
over again.

The Mutex version ends up with many more objects sitting in ObjectSpace 
than the Sync based version has, and while the Sync based version's 
object counts are pretty consistent, the Mutex version's are volatile, 
jumping up and down wildly, with a trend towards an increasing average 
count.

However, I don't think that's the whole story here.  Sync, because it is a 
lot more complex, it also a lot slower than Mutex.  This speed issue is 
part of the key to the appearance that Mutex leaks while Sync does not.

If I add one line to the test code that uses a Mutex, I get very different 
results.

select(nil,nil,nil,0.025)

The number of objects floating in objectspace at any given time, while 
still a bit more volatile than with the Sync version, is now close to the 
same overall numbers that I see in the Sync version, and does not show a 
continually upward trending average count.

In addition, RAM usage at the OS level does not continue to increase.

This strongly suggests to me that the reported leak in Mutex is no leak at 
all, and that impression is boltered by having looked at the Mutex code -- 
it's very simple and itself creates very few objects.

Rather, in the test cases, using a Mutex just lets the threads build 
objects faster than the GC thread can clean them up.  Slowing the threads 
down, either by using Sync, or by sticking a micro delay into them, gives 
the GC enough time to keep pace, and this is the only way that I have 
found to show any sort of leak with Mutex.


Kirk Haines