Forum: Ruby object scope and cleanup

Announcement (2017-05-07): www.ruby-forum.com is now read-only since I unfortunately do not have the time to support and maintain the forum any more. Please see rubyonrails.org/community and ruby-lang.org/en/community for other Rails- und Ruby-related community platforms.
Joshua B. (Guest)
on 2009-04-30 03:41
(Received via mailing list)
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,
>>     @tree.size.should == 2

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 H. (Guest)
on 2009-04-30 04:28
(Received via mailing list)
ball wrote:
> 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 -. (Guest)
on 2009-04-30 14:08
Joshua B. wrote:
> 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 D. (Guest)
on 2009-04-30 15:49
(Received via mailing list)
On Thu, Apr 30, 2009 at 6:08 AM, 7stud -- <removed_email_address@domain.invalid>
wrote:

> 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 H. (Guest)
on 2009-04-30 19:58
(Received via mailing list)
7stud -- wrote:
> 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.
This topic is locked and can not be replied to.