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 }
#<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
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
2010/7/5 Thierry L. [email protected]:
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
I don’t know WIN32OLE so I can’t tell whether there is another trick
that helps, sorry.
Kind regards
robert
On Mon, Jul 5, 2010 at 12:05 PM, Roger P. [email protected]
wrote:
I did a little writeup of it here:
Ruby Programming/Reference/Objects/GC - Wikibooks, open books for an open world
That write up is a bit bogus I’m afraid.
-
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.
-
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/
Github: rubyredrick (Rick DeNatale) · GitHub
Twitter: @RickDeNatale
WWR: http://www.workingwithrails.com/person/9021-rick-denatale
LinkedIn: http://www.linkedin.com/in/rickdenatale
Rick Denatale wrote:
On Mon, Jul 5, 2010 at 12:05 PM, Roger P. [email protected]
That write up is a bit bogus I’m afraid.
- 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…
- 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
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
ObjectSpace.each_object(Test) { |o| puts o.inspect }
#<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