Hi all,
Just ran into something very interesting with finalizers. I’ve found a
workaround (it’ll be obvious what it is from the code below), but I just
thought I’d share it for discussion’s sake.
Consider the code below:
$fcount = 0
class A
def initialize
end
end
class B
def initialize
end
def bar a
ObjectSpace.define_finalizer(a, lambda {|oid| $fcount += 1})
a = nil # xxx
nil
end
def foo
a = A.new
bar a
nil
end
end
b = B.new
for i in 1 … 10000
GC.start
b.foo
GC.start
end
$stderr.print “Program ends. #{$fcount} finalizers called.\n”
All but one of the finalizers run at the point of the trace.
Now, comment the line marked with xxx. This shouldn’t make any
difference- but it does. The program will report that 0 finalizers ran
at the point of the trace. You can confirm that the rest did run, but
they only ran at program exit, after the trace. Basically, the
resources are never released when finalizers are used. This is a big
problem in a long-running program.
If 10000 iterations isn’t enough, you can always increase the counter.
Note that I am using Ruby 1.9.2p136, Linux. Other versions may behave
differently.
Why the code above? I was noticing in my code that finalizers were
never being run under any circumstances. The above is a stripped-down
set of code that acts similarly to mine.
From a bit of research online, I’ve seen comments that say sometimes
values are left in registers, which affects GC. That seems fair enough
in general- but not here. There are 10000 objects here that aren’t being
finalized- they’re not in all in registers. If it’s the stack, then the
first run should also have failed. It’s not the return value, this is
nil. It’s not the parameter coming in, the first test would have failed.
Is it the current scope? I have a feeling that, based on the one line
change I made, that the current scope is somehow being captured by the
finaliser, so that if “a” remains set, the finaliser holds on to it, and
the object is never released. That’s just my theory- I could be wrong.
This situation is particularly bad if you want to set up a finaliser and
then immediately return the value (say, as a result of caching a value)-
the finaliser will never be called, because you can’t clear the value
before returning it.
If you’ve followed me so far, you can probably guess the workaround-
call a separate method to set the finaliser, and clear the parameter
afterward in that call, then return to the caller with a nil return
value. It’s annoying, but not too painful.
What I am incredibly curious about is why this happens in the first
place- and why there doesn’t seem too much talk of this specific problem
when using finalizers online. Finalizers failing to work when used in
the current scope without explicitly clearing the object afterward seems
like the sort of problem other people should be running into more often.
It’s bizarre. I’m wondering what everyone else thinks of it. Have I
missed something?
Garth
