object scope and cleanup

[ball]

I am having trouble understanding Ruby object cleanup wrt scope. In
particular, I would think that an object is getting deleted, but it
turns out that is not the case. I have an RSpec test below. The
BinarySearchTree size is defined as:

def size
@count = ObjectSpace.each_object(TreeNode) {}
end

I have the following Spec code:

describe BinarySearchTree do

it "should have size ZERO to start with" do
@tree = BinarySearchTree.new
@tree.size.should == 0
end

it "should have a size of ONE when we insert an item" do
@tree = BinarySearchTree.new
@tree.insert(5);
@tree.size.should == 1
end

it "should have a size of TWO when we insert two items" do
@tree = BinarySearchTree.new
@tree.insert(5);
@tree.insert(3);
@tree.size.should == 2
end
end


And the problem is, that when I get to the last assertion,
It fails, saying that there are 3 objects (not 2). Presumably because
the previous BinarySearchTree didn't delete the TreeNode.

Can you explain why?
And what can I do about it? (including "don't use ObjectSpace that
way")

 

[Sebastian Hungerecker]

It fails, saying that there are 3 objects (not 2). Presumably because
the previous BinarySearchTree didn't delete the TreeNode.

Can you explain why?

Because the garbace collector doesn't destroy objects as soon as possible. He
destroys them when it's convenient or necessary.

And what can I do about it? (including "don't use ObjectSpace that
way")

Don't use ObjectSpace that way.
An object will be in ObjectSpace longer than it is used (sometimes much
longer), so the number of objects of a kind in ObjectSpace means nothing.

HTH,
Sebastian

 

[7stud --]

I am having trouble understanding Ruby object cleanup wrt scope. In
particular, I would think that an object is getting deleted, but it
turns out that is not the case.

In a language like C++,

out_of_scope == destruction

With garbage collectors,

out_of_scope == ready_for_destruction

When the object is destroyed and whether the object is ever destroyed,
is out of your hands. It may be the case that the gc never sees a need
to destroy the object, in which case the object gets wiped out of memory
only when your program ends and the operating system reclaims the
program's resources(and I believe even then it's still in memory!).

There is another current thread where the ruby gc is being discussed:

http://www.ruby-forum.com/topic/185559#new

 

[Rick DeNatale]

With garbage collectors,

out_of_scope == ready_for_destruction

Actually, "out of scope" isn't really the right concept here, the
storage taken up by an object is eligible to be reclaimed by a
properly implemented GC iff it is not reachable by transitive closure
from one or more of a known set of root objects (like globals, and
active stack frames).

--
Rick DeNatale

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

 

[Sebastian Hungerecker]

In a language like C++,

out_of_scope == destruction

Well if a variable containing an object goes out of scope, the object is
destroyed, yes. But if all variables containing a pointer to an object (the
only kind there is in ruby) go out of scope and you did not previously call
free or destroy, the object will simply remain in memory forever.