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
on 2014-02-21 23:35
on 2014-02-22 00:05
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.
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
on 2014-02-23 15:15
On Sat, Feb 22, 2014 at 3:50 PM, Paul Robinson <firstname.lastname@example.org> 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.
on 2014-02-23 16:21
OK I'll press on and ignore the memory issues unless they come back to bite :D
on 2014-02-23 17:53
On Sun, Feb 23, 2014 at 9:14 AM, Alex Chaffee <email@example.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