5 ms·

> complexity works against safety. Not always. Java programs have fewer memory-management issues than C programs, and they tend to be less severe.

ncmncm 6y ago
The evidence does not support this assertion. Certainly C programs have a poor record of memory usage errors, but the habit of Java programs routinely needing orders of magnitude more memory to do similar work is well known. Memory leaks are as easy under GC as in C.
- whateveracct 6y ago
  > Memory leaks are as easy under GC as in C. This is just untrue. And no, allocating a bunch of short-lived objects isn't leaked memory. Neither is the overhead of the GC.
  - ncmncm 6y ago
    It is very easy to leak Java objects, simply by failing to remove them from containers when their usefulness has ended. 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.
    - whateveracct 6y ago
      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.
- MaxBarraclough 6y ago
  > The evidence does not support this assertion. 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.
- zelly 6y ago
  No it's not. Research generational garbage collection.
  - ncmncm 6y ago
    Research Java.
    - pjmlp 6y ago
      https://www.businesswire.com/news/home/20090302005701/en/Thales-Air-Systems-Selects-Aonix-PERC-Ultra https://www.businesswire.com/news/home/20090302005701/en/Tha...
      - MaxBarraclough 6y ago
        Interesting read, thanks. The cynic in me thinks 'deterministic garbage collection' is trivial depending on how you define it. 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.
        pjmlp 6y ago
        I can post other articles, unfortunately the anti-GC crowd (in general) seems to think GC == whatever I know of the JVM on my computer and is completely oblivious of the various kinds of options available out there. 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.
        6y ago

ncmncm 6y ago

The evidence does not support this assertion. Certainly C programs have a poor record of memory usage errors, but the habit of Java programs routinely needing orders of magnitude more memory to do similar work is well known. Memory leaks are as easy under GC as in C.

whateveracct 6y ago
> Memory leaks are as easy under GC as in C. This is just untrue. And no, allocating a bunch of short-lived objects isn't leaked memory. Neither is the overhead of the GC.
- ncmncm 6y ago
  It is very easy to leak Java objects, simply by failing to remove them from containers when their usefulness has ended. 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.
  - whateveracct 6y ago
    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.
MaxBarraclough 6y ago
> The evidence does not support this assertion. 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.
zelly 6y ago
No it's not. Research generational garbage collection.
- ncmncm 6y ago
  Research Java.
  - pjmlp 6y ago
    https://www.businesswire.com/news/home/20090302005701/en/Thales-Air-Systems-Selects-Aonix-PERC-Ultra https://www.businesswire.com/news/home/20090302005701/en/Tha...
    - MaxBarraclough 6y ago
      Interesting read, thanks. The cynic in me thinks 'deterministic garbage collection' is trivial depending on how you define it. 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.
      - pjmlp 6y ago
        I can post other articles, unfortunately the anti-GC crowd (in general) seems to think GC == whatever I know of the JVM on my computer and is completely oblivious of the various kinds of options available out there. 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.
        6y ago