There's a circular reference there: c1 points to 2 (created internally on=
=20
1), 2 points to 3 (created internally on 2), and 3 points to c1, which is=
a=20
reference at root (?) level there and again points to an internal 2, that=
=20
points to 3, that points to c1 ...

My question is, when assigning nil to c1, it should not invalidate all th=
e=20
inner objects and becomes available for garbage collection?
On the example above, I assigned nil to c1 and c4.next (5), and after the=
=20
GC.start I don't have 5, but still have c1 (same id), 2 and 3. On that=20
case, that memory will never be sweeped (free)? Because seems that I'll=20
always have a Object with id -604874856 and will not have a way to refer =
to=20
it later, for use or free the allocated memory for it.

Advertisements

"Eustaquio Rangel de Oliveira Jr." <> writes:
> My question is, when assigning nil to c1, it should not invalidate all
> the inner objects and becomes available for garbage collection?
> On the example above, I assigned nil to c1 and c4.next (5), and after
> the GC.start I don't have 5, but still have c1 (same id), 2 and 3. On
> that case, that memory will never be sweeped (free)? Because seems
> that I'll always have a Object with id -604874856 and will not have a
> way to refer to it later, for use or free the allocated memory for it.

Ruby's GC is lazy and conservative. Lazy meaning, it does not
exhaustively try to do path-finding on each object because for some
objects, path-finding is an expensive process. Conservative meaning,
if it is not doing a path-finding on an object, that object is not
freed.

Hate it or love it. It has both advantages and disadvantages. You have
just shown a disadvantage. But it can be mitigated by exiting the
scope which should make path-finding to those objects cheaper.

| Ruby's GC is lazy and conservative. Lazy meaning, it does not
| exhaustively try to do path-finding on each object because for some
| objects, path-finding is an expensive process. Conservative meaning,
| if it is not doing a path-finding on an object, that object is not
| freed.
|
| Hate it or love it. It has both advantages and disadvantages. You have
| just shown a disadvantage. But it can be mitigated by exiting the
| scope which should make path-finding to those objects cheaper.

I'll search about lazy and conversative gc's.
Just another question: if I use a method there, and not a begin/end block,
like this

"Eustaquio Rangel de Oliveira Jr." <> writes:
> -----BEGIN PGP SIGNED MESSAGE-----
> Hash: SHA1
>
> Hi!
>
> Thanks for the answer.
>
> | Ruby's GC is lazy and conservative. Lazy meaning, it does not
> | exhaustively try to do path-finding on each object because for some
> | objects, path-finding is an expensive process. Conservative meaning,
> | if it is not doing a path-finding on an object, that object is not
> | freed.
> |
> | Hate it or love it. It has both advantages and disadvantages. You have
> | just shown a disadvantage. But it can be mitigated by exiting the
> | scope which should make path-finding to those objects cheaper.
>
> I'll search about lazy and conversative gc's.
> Just another question: if I use a method there, and not a begin/end block,
> like this
>
> - --------------------------------------------------------------------------
> def test
> c1 = CustomObject.new("1",CustomObject.new("2",CustomObject.new("3")))
> c4 = CustomObject.new("4",CustomObject.new("5"))
> c6 = CustomObject.new("6")
> c1.next.next.next = c1 # comment this and check again
> list
> end
>
> test
> GC.start
> sleep(1)
> list
> - --------------------------------------------------------------------------
>
> After run this, only c6 remains. It's about scope also?
>

Funny, I couldn't reproduce what you are seeing. I cut and paste the
code you have and run it:

1) What sort of scope does begin..end introduce? In the comments to
his post, why writes "Variables declared inside a begin..end or
inside a block are block local, they perish with the close of the
block." But my own experience seems to contradict why's statement.
This program does not throw an error:

#!/usr/local/bin/ruby
begin
x = 1
end
p x

2) Why are people getting different results when they run the CustObj
garbage collection code? When I run it, Object 1 never gets collected
by GC, even after exiting the begin..end scope.

On 13 Jul 2005, at 06:43, Jay Cotton wrote:
> I've been following this thread as well as why's post (and the
> comments) at:
>
> http://redhanded.hobix.com/inspect/
> stuffingYourHandDownTheDisposal.html
>
> and I'm left confused about 2 things:
>
> 1) What sort of scope does begin..end introduce? In the comments to
> his post, why writes "Variables declared inside a begin..end or
> inside a block are block local, they perish with the close of the
> block." But my own experience seems to contradict why's statement.
> This program does not throw an error:
>
> #!/usr/local/bin/ruby
> begin
> x = 1
> end
> p x

begin does not create a new scope. why made a mistake here.
> 2) Why are people getting different results when they run the
> CustObj garbage collection code? When I run it, Object 1 never gets
> collected by GC, even after exiting the begin..end scope.
>
> Can anybody help me understand?

The GC is very finicky, so you may or may not get the same behavior
as other people do. That's part of the nature of Ruby's conservative
GC.

Share This Page

Welcome to The Coding Forums!

Welcome to the Coding Forums, the place to chat about anything related to programming and coding languages.

Please join our friendly community by clicking the button below - it only takes a few seconds and is totally free. You'll be able to ask questions about coding or chat with the community and help others.
Sign up now!