Re: Class variables and deleting objects

Ruby
1

Paul R. 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

2

On Fri, Feb 21, 2014 at 4:33 PM, Dave A. <
[email protected]> 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.

3

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 :smiley: ) 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

4

On Sat, Feb 22, 2014 at 3:50 PM, Paul R. [email protected]
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
Demystifying the Ruby GC or
Generational GC in Python and Ruby - Pat Shaughnessy
but seriously, don’t worry about it until you’re comfortable with GC
in the abstract.

5

On Sun, Feb 23, 2014 at 9:14 AM, Alex C. [email protected] 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

6

OK I’ll press on and ignore the memory issues unless they come back to
bite :smiley: