Fun with finalizers

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