In message <1175334819.468800.137310 / p77g2000hsh.googlegroups.com>, dima <dejan.dimic / gmail.com> writes >If you keep a reference to some object is something you do on >purpose. Unless there is an error in your logic. Perhaps you forgot to clear the reference(s) to the object when you were finished with it? Perhaps the design changed and you forgot to clear the reference, or forgot to call a method that cleared the reference. No different to a memory leak in a non-garbage collected language. Engineers don't put errors in programs deliberately (well, if you've got one, you need to sack them), they happen by mistake, design error, tiredness, Friday afternoons, etc. Thats life, stuff happens. That is why since Java came on the scene companies like Sitraka (with JProbe in 1996) and many others since have produced tools to detect such situations. Its also why we created Ruby Memory Validator, because such problems do exist for some applications. http://www.softwareverify.com/ruby/memory/index.html The main problem with leaks in garbage collected programs is that by their very nature (an unwanted reference is held) they are harder to detect than for non-garbage collected programs. The statement you write above makes me think you have not truly experienced a memory leak situation in a GC'd application (regardless of language - the principles remain the same). I mention Sitraka as they were the first company I am aware of that released a commercial tool for this task. They also published an article in Dr Dobbs detailing their position on this area and the terms they used. They called an unwanted object a "loiterer" if I recall correctly. There were three types: o Unwanted object references held longer than necessary by accident (the typical memory leak scenario). This reference could be stored in a static data member (class member) or in a dynamic data member (instance member) o Temporary object on stack held for longer than necessary, preventing potentially large object trees from being collected someFunc() { obj = createALargeNumerOfObjectsAndGiveMeTheRoot(); doSomeWork(obj); doSomeOtherWorkThatCouldDoWithMemoryReclaim(); } obj could be reclaimed after doSomeWork() (assuming the stack ref is the only reference to it) but because it is on the stack it can't be. A better way to do this would be to create a local scope for it (yes, there are other variantions, this is just to demo the point) someFunc() { { obj = createALargeNumerOfObjectsAndGiveMeTheRoot(); doSomeWork(obj); } doSomeOtherWorkThatCouldDoWithMemoryReclaim(); } o Some other case I can't recall right now (sorry I have a horrible cold and don't feel so good, so memory not working so good...). I'm pretty sure there was a third case, but it eludes me. Sorry. It quite interesting watching the Ruby community have the same discussions (and same misconceptions) about memory as happened in the Java community over a decade ago. I've found a reference to Sitraka's work here: Its a powerpoint presentation. For all of you that think memory leaks can't happen in a GC'd environment please take a look. Its a not a leak in the terms of a C memory leak, but you are still chewing through memory. These are different presentations, found using a simple Google search: http://www.java-forum-stuttgart.de/jfs/2001/folien/C2.ppt http://java.quest.com/JUG/meetings/presentations/sep02/JUG%20Sept%202002. PPT I hope you find them interesting. They apply to Ruby just as much as they do to Java. Stephen -- Stephen Kellett Object Media Limited http://www.objmedia.demon.co.uk/software.html Computer Consultancy, Software Development Windows C++, Java, Assembler, Performance Analysis, Troubleshooting Reg Office: 24 Windmill Walk, Sutton, Ely, Cambs CB6 2NH.