# Garbage Collection on Windoze

**URL:** <https://www.ruby-forum.com/t/garbage-collection-on-windoze/191078>\
**Category:** Ruby\
**Created:** [July 4, 2010, 6:36pm UTC](https://www.ruby-forum.com/t/garbage-collection-on-windoze/191078 "2010-07-04T18:36:31Z")\
**Posts on this page:** 8\
**Page:** 1

<div class="post-metadata">

**Author:** ![thyresias](https://www.ruby-forum.com/letter_avatar_proxy/v4/letter/t/a3d4f5/32.png) [@thyresias](https://www.ruby-forum.com/u/thyresias)\
**Post date:** [July 4, 2010, 6:36pm UTC](https://www.ruby-forum.com/t/garbage-collection-on-windoze/191078/1 "2010-07-04T18:36:31Z")

</div>

Minasan konbanha

I have a question about garbage collection. In short, I thought that  
releasing any reference to an object, and then calling GC.start would  
garbage-collect the object. It turns out not to be true (on Windoze),  
and I’ve been scratching my head to understand what’s going on (in  
vain).

Here’s the problem:

class Test  
end

class Inner \< Test  
end

class Outer \< Test  
def initialize  
@inner = Inner.new  
end  
def free  
@inner = nil  
end  
end

o = Outer.new  
o.free  
GC.start

# Now inner object should be gone, right? Wrong:

ObjectSpace.each\_object(Test) { |o| puts o.inspect }

# =\> #Inner:0x40b4470

```
 #<Outer:0x40b4ff8 @inner=nil>

```

I’m using ruby 1.8.7p249, but I have the same results with 1.9.1p378.  
I’m on windoze (yeah, I know…). The problem does not appear on my Mac  
(Inner is gone after GC). Any idea about this, a workaround? I need to  
free OLE automation objects, that’s why…

Cheers  
– Thierry

---

<div class="post-metadata">

**Author:** ![thyresias](https://www.ruby-forum.com/letter_avatar_proxy/v4/letter/t/a3d4f5/32.png) [@thyresias](https://www.ruby-forum.com/u/thyresias)\
**Post date:** [July 4, 2010, 7:15pm UTC](https://www.ruby-forum.com/t/garbage-collection-on-windoze/191078/2 "2010-07-04T19:15:57Z")

</div>

On 04.07.2010 18:36, Thierry L. wrote:

> I have a question about garbage collection. In short, I thought that  
> releasing any reference to an object, and then calling GC.start would  
> garbage-collect the object. It turns out not to be true (on Windoze),  
> and I’ve been scratching my head to understand what’s going on (in  
> vain).

There is no guarantee for GC. For efficiency reasons most GC  
implementations do not simply delete all objects once there is no life  
reference to them any more. Even if you explicitly start a collection  
there is no guarantee.

Kind regards

robert

---

<div class="post-metadata">

**Author:** ![thyresias](https://www.ruby-forum.com/letter_avatar_proxy/v4/letter/t/a3d4f5/32.png) [@thyresias](https://www.ruby-forum.com/u/thyresias)\
**Post date:** [July 5, 2010, 7:53am UTC](https://www.ruby-forum.com/t/garbage-collection-on-windoze/191078/3 "2010-07-05T07:53:40Z")

</div>

Robert K. wrote:

> There is no guarantee for GC. For efficiency reasons most GC  
> implementations do not simply delete all objects once there is no life  
> reference to them any more. Even if you explicitly start a collection  
> there is no guarantee.  
> Thanks Robert, I kind of had this reservation in the back of my head, so  
> I’m more looking for a workaround: in real life, the Inner object would  
> be an application started through OLE automation, for instance Excel,  
> Word, Access… The problem is that the application won’t close after  
> sending it a Quit: it will close after being garbage-collected. Any idea  
> how I can control the fact that WIN32OLE objects are actually freed?  
> (ole\_free does not work well, and I won’t complain since the doc says we  
> should not use it…)

---

<div class="post-metadata">

**Author:** ![thyresias](https://www.ruby-forum.com/letter_avatar_proxy/v4/letter/t/a3d4f5/32.png) [@thyresias](https://www.ruby-forum.com/u/thyresias)\
**Post date:** [July 5, 2010, 12:37pm UTC](https://www.ruby-forum.com/t/garbage-collection-on-windoze/191078/4 "2010-07-05T12:37:13Z")

</div>

2010/7/5 Thierry L. [removed\_email\_address@domain.invalid](mailto:removed_email_address@domain.invalid):

> how I can control the fact that WIN32OLE objects are actually freed?  
> (ole\_free does not work well, and I won’t complain since the doc says we  
> should not use it…)

There is generally no way to control when an object will be collected  
unless you start hacking the interpreter. For proper resource  
deallocation you usually use begin - ensure, but this can only work by  
invoking methods not forcing destruction of objects. See also

[http://blog.rubybestpractices.com/posts/rklemme/002\_Writing\_Block\_Methods.html](http://blog.rubybestpractices.com/posts/rklemme/002_Writing_Block_Methods.html)

I don’t know WIN32OLE so I can’t tell whether there is another trick  
that helps, sorry.

Kind regards

robert

---

<div class="post-metadata">

**Author:** ![thyresias](https://www.ruby-forum.com/letter_avatar_proxy/v4/letter/t/a3d4f5/32.png) [@thyresias](https://www.ruby-forum.com/u/thyresias)\
**Post date:** [July 5, 2010, 10:32pm UTC](https://www.ruby-forum.com/t/garbage-collection-on-windoze/191078/5 "2010-07-05T22:32:36Z")

</div>

On Mon, Jul 5, 2010 at 12:05 PM, Roger P. [removed\_email\_address@domain.invalid](mailto:removed_email_address@domain.invalid)  
wrote:

> I did a little writeup of it here:
> 
> [Ruby Programming/Reference/Objects/GC - Wikibooks, open books for an open world](http://en.wikibooks.org/wiki/Ruby_Programming/Reference/Objects/GC#Conservative)

That write up is a bit bogus I’m afraid.

1. The MRI GC is NOT conservative, it guards calls to gc\_mark and it’s  
ilk by using the C function is\_pointer\_to\_heap, since it marks objects  
by setting bits in the object’s header (the first word pointed to by a  
potential object reference) marking a non-object by mistake would lead  
to seriously hard to debug problems.

2. Although a conservative GC, if Ruby actually used it, could cause  
objects to live past the point that could no longer really be reached,  
many garbage collectors have the property that there is no guarantee  
that unreachable objects are collected as soon as possible, only that  
objects will NOT be collected as log as they are alive.

–  
Rick DeNatale

Blog: [http://talklikeaduck.denhaven2.com/](http://talklikeaduck.denhaven2.com/)  
Github: [rubyredrick (Rick DeNatale) · GitHub](http://github.com/rubyredrick)  
Twitter: @RickDeNatale  
WWR: [http://www.workingwithrails.com/person/9021-rick-denatale](http://www.workingwithrails.com/person/9021-rick-denatale)  
LinkedIn: [http://www.linkedin.com/in/rickdenatale](http://www.linkedin.com/in/rickdenatale)

---

<div class="post-metadata">

**Author:** ![thyresias](https://www.ruby-forum.com/letter_avatar_proxy/v4/letter/t/a3d4f5/32.png) [@thyresias](https://www.ruby-forum.com/u/thyresias)\
**Post date:** [July 6, 2010, 12:03am UTC](https://www.ruby-forum.com/t/garbage-collection-on-windoze/191078/6 "2010-07-06T00:03:59Z")

</div>

Rick Denatale wrote:

> On Mon, Jul 5, 2010 at 12:05 PM, Roger P. [removed\_email\_address@domain.invalid](mailto:removed_email_address@domain.invalid)

> That write up is a bit bogus I’m afraid.
> 
> 1. The MRI GC is NOT conservative, it guards calls to gc\_mark and it’s  
> ilk by using the C function is\_pointer\_to\_heap, since it marks objects  
> by setting bits in the object’s header (the first word pointed to by a  
> potential object reference) marking a non-object by mistake would lead  
> to seriously hard to debug problems.

Hmm. Perhaps our definitions of conservative differ? To me  
conservative means that it doesn’t necessarily collect objects without  
references…

> 1. Although a conservative GC, if Ruby actually used it, could cause  
> objects to live past the point that could no longer really be reached,  
> many garbage collectors have the property that there is no guarantee  
> that unreachable objects are collected as soon as possible, only that  
> objects will NOT be collected as log as they are alive.

True, but not MRI that I’m aware, except objects with finalizers I  
suppose.  
Oh feel free to change the content on that wiki page nothing sacred  
there.

-r

---

<div class="post-metadata">

**Author:** ![thyresias](https://www.ruby-forum.com/letter_avatar_proxy/v4/letter/t/a3d4f5/32.png) [@thyresias](https://www.ruby-forum.com/u/thyresias)\
**Post date:** [July 6, 2010, 7:32am UTC](https://www.ruby-forum.com/t/garbage-collection-on-windoze/191078/7 "2010-07-06T07:32:42Z")

</div>

I keep thinking there is something to dig in this, but unfortunately I  
will have no time to do it. Also, after re-checking, contrary to what I  
posted first, I have the same problem on Mac: in between, I upgraded my  
Mac ruby from 186 to 187…  
Thanks anyway for the feedback.  
Cheers  
– Thierry

---

<div class="post-metadata">

**Author:** ![thyresias](https://www.ruby-forum.com/letter_avatar_proxy/v4/letter/t/a3d4f5/32.png) [@thyresias](https://www.ruby-forum.com/u/thyresias)\
**Post date:** [July 5, 2010, 6:05pm UTC](https://www.ruby-forum.com/t/garbage-collection-on-windoze/191078/8 "2010-07-05T18:05:20Z")

</div>

> ObjectSpace.each\_object(Test) { |o| puts o.inspect }
> 
> # =\> #Inner:0x40b4470
> 
> ```
> #<Outer:0x40b4ff8 @inner=nil>
> 
> ```
> 
> I’m using ruby 1.8.7p249, but I have the same results with 1.9.1p378.  
> I’m on windoze (yeah, I know…). The problem does not appear on my Mac  
> (Inner is gone after GC). Any idea about this, a workaround? I need to  
> free OLE automation objects, that’s why…

Yeah get the same thing here. It’s the nature of conservative GC.  
I did a little writeup of it here:

[http://en.wikibooks.org/wiki/Ruby\_Programming/Reference/Objects/GC#Conservative](http://en.wikibooks.org/wiki/Ruby_Programming/Reference/Objects/GC#Conservative)

-r