How to understand why object is not collected?

Ruby
1

Hi all.

Here’s a problem.

I have some object of MyClass with complex “freeing” logic, and I want
to
test this logic.
I do:

span = … #somehow created object

ObjectSpace.define_finalizer(span, proc{p “gc ok”}) #define test
finalizer

span.detach #remove object from all of my internal caches, no
references
to object should exist

span = nil #remove the last reference to object

GC.start #<===HERE the object must be collected and finalized

p “end of code”

I expect:

“gc ok”
“end of code”

I receive:

“end of code”
“gc ok”

OK, I suppose there are some references to the object still exists. I
want
to know, at least, what number of references still exists (in ideal, I’d
want to know, where they are).
How I can? (except of harcode hacking GC’s C code)

Ruby 1.9 (downloaded a week ago), Windows.

Thanks.

V.

2

Victor “Zverok” Shepelev wrote:

ObjectSpace.define_finalizer(span, proc{p “gc ok”}) #define test finalizer

span.detach #remove object from all of my internal caches, no references
to object should exist

span = nil #remove the last reference to object

GC.start #<===HERE the object must be collected and finalized

This is probably a situation where GC is being conservative. A simple
example:

class Foo; end

foo = Foo.new
foo = nil

GC.start

p ObjectSpace.each_object(Foo) {} # ==> 1

Probably this means that the Foo instance pointer is still visible
somewhere in the local frame.

But that doesn’t mean that there is a leak:

class Foo; end

10.times do
Foo.new
end

GC.start

p ObjectSpace.each_object(Foo) {} # ==> 1

In my experience, it’s hard to write precise unit tests for GC behavior,
and you end up with some fuzziness. The important property of GC is
really the asymptotic behavior.

3

On 2006.10.29 03:26, Victor Zverok S. wrote:

Hi all.

Here’s a problem.

I have some object of MyClass with complex “freeing” logic, and I want to
test this logic.

Hard to say what is going wrong but the solution is simple. Whenever
you have a resource that must be released, do it explicitly. The way
this is usually implemented is either:

f = File.open ‘foo’
puts f.read
f.close

Or, more conveniently

File.open(‘foo’) {|f| puts f.read}

The block-form uses ensure to make sure the file handle gets closed.

4

From: Joel VanderWerf [mailto:[email protected]]
Sent: Saturday, October 28, 2006 10:52 PM

p ObjectSpace.each_object(Foo) {} # ==> 1
OK, I’ve got it.

In my experience, it’s hard to write precise unit tests for GC behavior,
and you end up with some fuzziness. The important property of GC is
really the asymptotic behavior.

Just for now, I need no precise unit test. I just want to know, would
the
objects of MyClass collected in principle. Can I achieve the goal
somehow?

V.

5

Victor “Zverok” Shepelev wrote:

GC.start
objects of MyClass collected in principle. Can I achieve the goal somehow?
What about creating a lot of them in a loop, without keeping references?
Then I would expect GC to leave at most one instance.

6

From: Eero S. [mailto:[email protected]]
Sent: Saturday, October 28, 2006 11:20 PM

you have a resource that must be released, do it explicitly. The way
The block-form uses ensure to make sure the file handle gets closed.
I know this (I was C++ guy foe many years, so RAII is my breath), but
can’t
use.
My objects are HTML DOM elements and I want to be sure they are GC’d
when
detached from DOM and have no other references.

V.

7

From: Joel VanderWerf [mailto:[email protected]]
Sent: Saturday, October 28, 2006 11:26 PM

Just for now, I need no precise unit test. I just want to know, would the
objects of MyClass collected in principle. Can I achieve the goal
somehow?

What about creating a lot of them in a loop, without keeping references?
Then I would expect GC to leave at most one instance.

They can’t be created by .new, they created in correspondence to some
HTML
DOM by C extension.
Problem already solved by the trick:

–
def test
span = …
ObjectSpace.define_finalizer(span, proc{p “gc ok”})
span.detach
span = nil
end

test

GC.start

p “end of code”

Output corresponds to my expectations (gc ok => end of code)

Thanks for your help!

V.