Perhaps, but it points out the often overlooked truth that using a garbage collected language is substituting one set of memory problems for another. I can't tell you how much of my time at work is spent trying to work around the java garbage collector because I can't manually destroy objects.
No, the title is misleading. It was misleading on reddit too.
> ... because I can't manually destroy objects.
I'm not sure about Java, but if it's similar to C# then you can manually destroy objects. When they get "officially" removed from memory is up to the garbage collector (that is, when more memory space is needed).
Also, its worth noting that you can not reclaim the memory of an object in Java, C# (http://blogs.msdn.com/clyon/archive/2004/09/21/232445.aspx), or any other garbage collected language. If you could, you would no longer have managed code. What you may be able to do in some languages is say "hey GC, I've got this object, I know its got no references, verify that and free the space now please". You can't do this in Java (or C# so far as I know). This is what I meant when I said destroy.
Why might someone need that level of control? Well in an ideal world you would not, but in reality (at least in Java), GC is highly JVM dependent, and on the JVM I use (and probably most if not all of them) GC makes no guarantee that objects available for collection will actually be collected. The OS X JVM in particular is pretty bad here (again, I'm guessing others are too), when you run out of memory, it doesn't even try to GC. Even if you call System.gc() you might not get any space reclaimed. Its ridiculous, but lots of people actually have a method that is basically "System.reallyGC()" which loops a whole bunch of times on System.gc() calls until it either gives up or reclaims some percentage of memory.
> you can not reclaim the memory of an object in Java, C#, or any other garbage collected language.
That's just not true. Python currently doesn't return memory from space allocated to primitive types but there's a branch that I'm using that will do that too which will be merged to that main soon. That's a pretty broad statement you're making.
Could you / do you use memory (object) pools? It's crazy to put C++ techniques on top of Java which is supposed to take all that off your hands but, as you say, 'in the real world'...
We use a lot of thread local pools so that we never allocate new objects. We generally have a fixed number of long lived threads, so this works out pretty well.
That just seems like very bad practice. System.gc() usually does not do anything, and it might seem as if a lot of memory is being used. Usually the gc kicks into gear if the memory is really needed, though.
Don't know the OS X jvm, but it can't be THAT bad...
I had some troubles with mobile phone JVMs, usually manually setting all pointers to null was doing the trick, though.
In any case, I wouldn't blame Java for some bad implementations of jvms.
I said "perhaps" because while it might be misleading in the sense that this isn't some discovered memory leak in the C# language, it is an example of how programming mistakes in garbage collected languages can still lead to "memory leaks". To be more specific, memory that you intended to be freed and made available was not. You can argue about the semantics, but I think the intent of saying memory leak is clear here in the context of the article.
I wasn't arguing about the term "memory leak", but the misleading title's implication that it's a design flaw in the C# specification (or, for that matter, Microsoft's or Mono's implementation). It's not. It's a memory leak due to the programmers error.
Never really had a problem with that - maybe you have an odd programming style (curious). Also, how is it substituting, if you don't have a garbage collector, you still have to free the memory.
