Garbage Collection on Windoze

[Thierry Lambert]

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

 

[Robert Klemme]

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

 

[Thierry Lambert]

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...)

 

[Robert Klemme]

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...)

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.h=
tml

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

Kind regards

robert

--=20
remember.guy do |as, often| as.you_can - without end
http://blog.rubybestpractices.com/

 

[Roger Pack]

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

-r

 

[Rick DeNatale]

Yeah get the same thing here. =A0It's the nature of conservative GC.
I did a little writeup of it here:

http://en.wikibooks.org/wiki/Ruby_Programming/Reference/Objects/GC#Conser= vative

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.



--=20
Rick DeNatale

Blog: http://talklikeaduck.denhaven2.com/
Github: http://github.com/rubyredrick
Twitter: @RickDeNatale
WWR: http://www.workingwithrails.com/person/9021-rick-denatale
LinkedIn: http://www.linkedin.com/in/rickdenatale

 

[Roger Pack]

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...

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.

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

 

[Thierry Lambert]

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