3 ms·

Neither of those is really a memory leak imo. The first one is a "retainer" leak in a way, but in your average Java use-case (e.g. an HTTP request handler) you

Neither of those is really a memory leak imo. The first one is a "retainer" leak in a way, but in your average Java use-case (e.g. an HTTP request handler) you have to make a pretty uncommon mistake for any allocation to outlive its usefulness and grow unbounded without being collected. 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.)

ncmncm 6y ago
Tomato, Tomahto. 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.
- MaxBarraclough 6y ago
  I agree, that should count as memory leak. If we're wrongfully retaining an object long after it should have been deallocated, that's a memory leak. The particulars of the language and the memory-management strategy, aren't the point. 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-security-bugs-are-memory-safety-issues/ https://www.zdnet.com/article/microsoft-70-percent-of-all-se...
  - ncmncm 6y ago
    Those are not leaks.
    - MaxBarraclough 6y ago
      True. I wasn't able to find a good source on how common memory leaks are in modern C code. Do you have one? 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.
      - ncmncm 6y ago
        Yes, double-free and use-after-free are no end of trouble in C programs (and, incidentally, vanishingly rare in C++ programs), but this thread is specifically about leaks in C and in GC languages (and which are also vanishingly rare in C++ programs).
- whateveracct 6y ago
  Generational GCs tend to have a fixed 2x memory overhead. Is that 2x a memory leak? Because it comes with the benefit of allocations being bumps and de-allocation being proportional to working set (not garbage size)
TheCoelacanth 6y ago
That's a GC-centric definition of "memory leak" that was invented to make garbage collection a tractable problem. 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.
- whateveracct 6y ago
  But like I said, in most Java-based use-cases, the memory allocated is free by the end of the function call/request.

ncmncm 6y ago

Tomato, Tomahto. 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.

MaxBarraclough 6y ago
I agree, that should count as memory leak. If we're wrongfully retaining an object long after it should have been deallocated, that's a memory leak. The particulars of the language and the memory-management strategy, aren't the point. 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-security-bugs-are-memory-safety-issues/ https://www.zdnet.com/article/microsoft-70-percent-of-all-se...
- ncmncm 6y ago
  Those are not leaks.
  - MaxBarraclough 6y ago
    True. I wasn't able to find a good source on how common memory leaks are in modern C code. Do you have one? 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.
    - ncmncm 6y ago
      Yes, double-free and use-after-free are no end of trouble in C programs (and, incidentally, vanishingly rare in C++ programs), but this thread is specifically about leaks in C and in GC languages (and which are also vanishingly rare in C++ programs).
whateveracct 6y ago
Generational GCs tend to have a fixed 2x memory overhead. Is that 2x a memory leak? Because it comes with the benefit of allocations being bumps and de-allocation being proportional to working set (not garbage size)

TheCoelacanth 6y ago

That's a GC-centric definition of "memory leak" that was invented to make garbage collection a tractable problem. 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.

whateveracct 6y ago
But like I said, in most Java-based use-cases, the memory allocated is free by the end of the function call/request.