Memory leaks are as easy under GC as in C.
What are you referring to?
> C programs have a poor record of memory usage errors
Right. The C language allows for all manner of memory-related failures that are impossible in a language like Java. Use-after-free, double-free, and dereferencing NULL, are all undefined behaviour in C. In Java, the first two are impossible, and attempting to dereference null throws an exception. It's possible to do screwy things with Java finalisers, mind.
> the habit of Java programs routinely needing orders of magnitude more memory to do similar work is well known
Sure, but that's a matter of efficiency, with no bearing on memory safety.
> Memory leaks are as easy under GC as in C.
They're still possible, but I sincerely doubt they happen with equal frequency between the two languages. I don't know of a good study on this empirical question though.
This is just untrue. And no, allocating a bunch of short-lived objects isn't leaked memory. Neither is the overhead of the GC.
And all the memory not yet collected has effectively leaked until the next reclaim cycle, which might never happen.
So, memory leaks are as easy under GC as in C.
Whereas in C you literally have to call free manually. That is way more error-prone than the ways you leak memory in Java.
Once again, using too much memory or the GC running "eventually" are not leaks they are just not optimized memory management (a heavily fetishized thing in our profession.)
The effect is using manyX more memory than even the leaky C program, and very hard to find and fix.
Malloc leaks are trivial to locate with valgrind, so for practical purposes they don't even exist, in the wild, in programs under any kind of maintenance.
I disagree though that memory leaks are common in Java programs. Again though I don't know of a quantitative study on this, unfortunately.
> The effect is using manyX more memory than even the leaky C program
That will depend on the programs.
> very hard to find and fix
I can't comment from experience, but I can believe this.
> Malloc leaks are trivial to locate with valgrind, so for practical purposes they don't even exist, in the wild, in programs under any kind of maintenance.
This is false. Issues with memory management are responsible for many real-world security issues with C code. https://www.zdnet.com/article/microsoft-70-percent-of-all-se...
I'd be surprised if memory leaks are far less common than double-free, use-after-free, dereferencing NULL, and out-of-bounds access. I'd expect they'd be roughly equally difficult to detect, either manually or using tooling like Valgrind and static-analysers. I'd also expect memory-leaks to be of generally less concern, and therefore less 'newsworthy', as a small memory leak isn't as likely to pose a real problem as any of the other errors.
Memory that is retained that will never be used regardless of input to the program is effectively a memory leak, regardless of whether you can get to it through some chain of references.
1. Start off with an ordinary JVM with a non-concurrent, non-parallel GC. Doesn't matter if it's generational.
2. Take an extremely conservative estimate of the worst-case full-GC pause time, given the hardware (ideally with excessively powerful hardware)
3. Set up the system to invoke full-GC every frame
We've now defined a system that will cope with GC pauses just fine, but we haven't done any real engineering. Their offering clearly isn't that lazy, they've apparently written their own AOT compiler, but it's hard to gauge how technically impressive their GC is.
Ironically it tends to be the same crowd that is unware that high performance C usually doesn't use libc malloc()/free(), and there are companies that used to make a business out of selling specialized heap management libraries.
Aicas is the current steward company of the specification.
https://www.aicas.com/download/rtsj/rtsj_76.pdf
Books like "Hard Realtime Garbage Collection in Modern Object Oriented Programming Languages", from one of the Aicas' founders are quite interesting reads.
https://www.amazon.com/Realtime-Collection-Oriented-Programm...
Many discuss drop frames and jitter, while forgetting that a couple of ms more can result in someone's death in industrial automation or getting the wrong guys dead in weapon control systems.