# Garbage collection/memory unfreed problem

**URL:** <https://www.ruby-forum.com/t/garbage-collection-memory-unfreed-problem/74805>\
**Category:** Ruby\
**Created:** [November 7, 2006, 10:57am UTC](https://www.ruby-forum.com/t/garbage-collection-memory-unfreed-problem/74805 "2006-11-07T10:57:21Z")\
**Posts on this page:** 3\
**Page:** 1

<div class="post-metadata">

**Author:** ![scorintha](https://www.ruby-forum.com/letter_avatar_proxy/v4/letter/s/278dde/32.png) [@scorintha](https://www.ruby-forum.com/u/scorintha)\
**Post date:** [November 7, 2006, 10:57am UTC](https://www.ruby-forum.com/t/garbage-collection-memory-unfreed-problem/74805/1 "2006-11-07T10:57:21Z")

</div>

It appears that the ruby garbage collector is not freeing up unused  
memory on my linux machine, but IS on my windows machine… I’m baffled  
and troubled. Any advice would be appreciated…

Using the attached test script, in linux I observe the VMRSS start at  
around 1.5Meg, then go up to ~20Meg by iteration 3 or 4, and sit there  
for the remaining iterations. Then once the t array goes out of scope, I  
see it drop by a few meg. The GC.start only drops apparent memory  
consumption to ~14Meg.

Meanwhile, on windows XP, I see it increase to around 20Meg, then sit  
around there until the GC.free, which brings it back down to around  
5Meg, close to the starting point.

Can anybody explain the difference here? Is the 14meg _really_  
unavailable to the OS in linux?

* * *

class Grab  
def initialize  
@myhash={}  
0.upto(100000) {|i| @myhash[i]="#{i} Im a part of a hash"}  
end  
end

def memuse  
#IO.read("/proc/#{Process.pid}/status") =~ /VmSize.\* (\d+) k/  
“Hi”  
end

puts “Mem before anything: #{memuse}”  
sleep 10;  
0.upto(10) do |x|  
t||=Array.new  
t[x]=Grab.new  
puts “Mem in scope #{x}: #{memuse}”  
sleep 1;  
end  
puts “mem out of scope #{memuse}”  
sleep 10;  
GC.start  
puts “Mem after GC: #{memuse}”  
sleep 10;

---

<div class="post-metadata">

**Author:** ![scorintha](https://www.ruby-forum.com/letter_avatar_proxy/v4/letter/s/278dde/32.png) [@scorintha](https://www.ruby-forum.com/u/scorintha)\
**Post date:** [November 7, 2006, 10:57am UTC](https://www.ruby-forum.com/t/garbage-collection-memory-unfreed-problem/74805/2 "2006-11-07T10:57:36Z")

</div>

Hi Mark,

I tried your code on a RHEL4 x86-64 server and I got the same problem  
(the RSS size was even bigger). I also tried repeating your main loop  
for several times, and the RSS size (after GC) increased each time. So  
I think this is inefficiency in Ruby’s GC implementation.

Since it’s RSS, physical pages have been allocated for the Ruby  
process’s data section, I don’t think Linux can use this part of memory  
for other purpose, unless the Ruby process is killed by the OOM killer  
☹

I don’t know the reason for this problem but I’ll try to find out.

Lei Ming

---

<div class="post-metadata">

**Author:** ![scorintha](https://www.ruby-forum.com/letter_avatar_proxy/v4/letter/s/278dde/32.png) [@scorintha](https://www.ruby-forum.com/u/scorintha)\
**Post date:** [November 7, 2006, 11:04am UTC](https://www.ruby-forum.com/t/garbage-collection-memory-unfreed-problem/74805/3 "2006-11-07T11:04:36Z")

</div>

On Nov 2, 2006, at 9:55 PM, Mark N. wrote:

> consumption to ~14Meg.
> 
> Meanwhile, on windows XP, I see it increase to around 20Meg, then sit  
> around there until the GC.free, which brings it back down to around  
> 5Meg, close to the starting point.
> 
> Can anybody explain the difference here? Is the 14meg _really_  
> unavailable to the OS in linux?

Ruby’s garbage collector is conservative and walks the stack looking  
for pointers into the heap. If it finds a possible pointer to the  
heap the referenced memory will not be reclaimed. This can happen  
even if you’ve returned from a method that referenced a large object.

> “Hi”  
> puts “mem out of scope #{memuse}”  
> sleep 10;  
> GC.start  
> puts “Mem after GC: #{memuse}”  
> sleep 10;

–  
Eric H. - removed\_email\_address@domain.invalid - [http://blog.segment7.net](http://blog.segment7.net)  
This implementation is HODEL-HASH-9600 compliant

[http://trackmap.robotcoop.com](http://trackmap.robotcoop.com)