Forum: Ruby Re: Class variables and deleting objects

Da4866904cd77478452d472640a40054?d=identicon&s=25 Dave Aronson (Guest)
on 2014-02-21 23:35
(Received via mailing list)
Paul Robinson wrote:

> I don't see how the garbage collector would help.

No?  That's exactly what it's for.

> How would it know which objects were 'dead' and could be removed?

There are many techniques, and it's such a general question I'd rather
not go into it here.  If you Google "how do garbage collectors work"
(preferably sans quotes), you'll get a ton of hits that will tell you
more than you ever wanted to know.

-Dave
Abdb670e1c130f96f947a94d03c02efa?d=identicon&s=25 Eric Christopherson (echristopherson)
on 2014-02-22 00:05
(Received via mailing list)
On Fri, Feb 21, 2014 at 4:33 PM, Dave Aronson <
ruby-talk.list.2.TRex@codosaur.us> wrote:

> (preferably sans quotes), you'll get a ton of hits that will tell you
> more than you ever wanted to know.


I read Paul's question as asking how it would know *in his program in
particular* it would know which objects to collect. Paul, basically any
time you have a reference to an object, it is alive and won't be
collected.
And you have a reference to an object whenever you have a variable which
appears as the left-hand side of an assignment expression, and also
whenever it's held in an array or hash or another object (e.g. as an
instance or class variable in that object or its class).

When all such references to an object are disconnected (e.g. you assign
the
variable another object value, or an object holding the reference itself
dies), your object will be put on a list to be eventually
garbage-collected. It doesn't happen instantly; Ruby has algorithms for
deciding when to do it. But I wouldn't expect it to let millions of
objects
to hang around for long.
399a991530e4bf70b979784f898fbaef?d=identicon&s=25 Paul Robinson (paulr)
on 2014-02-22 21:50
Once again, I failed to make the question clear enough - sorry about
that.

Yes, Eric that was what I meant to ask; I've always drilled myself to
handle the deletion of objects that were no longer required rather than
hoping that things would be taken care of automatically. I don't see it
as any different to creating a bunch of objects; if there are x extant
objects and I want to create another y in one go I'd have to do some
sort of calculation to see that they'd fit within memory (or put them in
a queue to be created when others are freed up).

I suppose in this scenario then, the only way to emulate this would be
to mark an object as dead and re-assign to that variable when a new
object was required. That would either mean keeping a list of objects
which could be re-used (I don't know how to do that in Ruby yet :D ) or
iterating through all objects until one flagged as dead was found. Both
of those would seem to hint at a performance hit if there were many
objects compared to calling a delete method in other languages.

Oh, hang on, what if I assign 'nil' to an object that is no longer
required, I imagine that will attract the attention of the GC? I suppose
I should go and try this out....

Thanks both

Paul
2cddfa1d5e719e79aeab4e351c1793e9?d=identicon&s=25 Alex Chaffee (alexch)
on 2014-02-23 15:15
(Received via mailing list)
On Sat, Feb 22, 2014 at 3:50 PM, Paul Robinson <lists@ruby-forum.com>
wrote:
> Oh, hang on, what if I assign 'nil' to an object that is no longer
> required, I imagine that will attract the attention of the GC?

No, the GC runs on its own schedule. If you want it to run immediately
you can ask it to, but in general that is a really bad idea. (So bad
that I'm not going to tell you how, since that might tempt you to
sprinkle it throughout your code.)

My advice? Free your mind from the tyranny of malloc/dealloc and let
Ruby carry the load. After a while you can go read something like
http://samsaffron.com/archive/2013/11/22/demystify... or
http://patshaughnessy.net/2013/10/30/generational-...
but seriously, don't worry about it until you're comfortable with GC
in the abstract.
399a991530e4bf70b979784f898fbaef?d=identicon&s=25 Paul Robinson (paulr)
on 2014-02-23 16:21
OK I'll press on and ignore the memory issues unless they come back to
bite :D
Da4866904cd77478452d472640a40054?d=identicon&s=25 Dave Aronson (Guest)
on 2014-02-23 17:53
(Received via mailing list)
On Sun, Feb 23, 2014 at 9:14 AM, Alex Chaffee <alex@stinky.com> wrote:

> My advice? Free your mind from the tyranny of malloc/dealloc
> and let Ruby carry the load.

AMEN!

It's been said (not sure if "officially", maybe Matz can confirm) that
"Ruby was designed to maximize programmer happiness".  What makes C
programmers UNhappy?  Memory leaks from not freeing malloc'ed objects,
and the drudgery of making sure that doesn't happen!  And I oughta
know, I put up with that for decades.

-Dave
Please log in before posting. Registration is free and takes only a minute.
Existing account

NEW: Do you have a Google/GoogleMail, Yahoo or Facebook account? No registration required!
Log in with Google account | Log in with Yahoo account | Log in with Facebook account
No account? Register here.