Memory Leak Torpedoed Princeton's DARPA Chances(codeproject.com)
codeproject.com
Memory Leak Torpedoed Princeton's DARPA Chances
http://www.codeproject.com/showcase/IfOnlyWedUsedANTSProfiler.asp
19 comments
Pretty misleading title - the issue wasn't a C# memory leak, it was that these developers didn't remove old objects from an event subscriber list...
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.
> Perhaps
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).
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.
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.
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.
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.
[deleted]
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.
And I wasn't arguing that the title wasn't misleading. Just that while it may be slightly misleading, the article itself clearly puts it in context.
perhaps: "used to express reluctant or qualified agreement or acceptance."
perhaps: "used to express reluctant or qualified agreement or acceptance."
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.
That's a god damn memory leak. What the hell.
Truth to be said, the title comes from slashdot, but hey guys, why argue about the title when the content is cool? I enjoyed the article and just for the record, I did understand the problem was a user memory leak and not something to do with C#.
> the title comes from slashdot
That explains it. From a site that uses a photoshop of Bill Gates/Borg hybrid for every Microsoft story, it's no wonder the title's misleading.
That explains it. From a site that uses a photoshop of Bill Gates/Borg hybrid for every Microsoft story, it's no wonder the title's misleading.
And if you call right now with the ANTS Profiler you'll get not just ONE license, but TWO licenses for 5 easy payments of $59.95. BUT THAT'S NOT ALL!! We'll throw in this FREE Profiler coffee mug, absolutely free! Operators are standing by!
Oh please, we're all whores. This story would only be spam if it were contrived to sell more ANTS software.
You will probably get down modded, but you are right. We are all whores of some sort, some of the time at least. Its actually liberating to make this realisation, and get over ourselves.