4 ms·

I was probably a little too JVM-centric in my post. What's a "stop the world GC"? I joke, of course, but I really haven't seen anything like that in a long, lo

I was probably a little too JVM-centric in my post. What's a "stop the world GC"? I joke, of course, but I really haven't seen anything like that in a long, long time. You're right about memory, but you're wrong when you propose C++ as a solution. C++ doesn't solve any of the problems you outlined. You can implement a solution to those problems in C++. A C++ program doesn't come with an inherent advantage in memory handling. Many of the same techniques (creating and managing pools of memory) can and are being done in applications (like Cassandra) on the JVM (off-heap memory). What you're really deciding is whether you want to solve those problems in a VM, or solve them at the application level. Garbage collectors give you two things -- a reliability backstop, and (when you take pointers away) increased security. The behavior of GC is something that can be tuned (often dynamically) for a particular environment.

Arelius 13y ago
> What's a "stop the world GC"? I joke, of course, but I really haven't seen anything like that in a long, long time. Actually, many modern GCs are still "stop the world" including many generational GCs. the alternative generally has overhead elsewhere that hurts performance. GC has a lot of tradeoffs. > A C++ program doesn't come with an inherent advantage in memory handling. Many of the same techniques (creating and managing pools of memory) can and are being done in applications (like Cassandra) on the JVM (off-heap memory). Sure, but it sure is a lot easier in C++ since the entire infrastructure doesn't assume GC is operating. I don't even know a way to reliably allocate a temporary object in Java that won't trigger GC I could guess some things that would probably cause the optimizer to allocate it on the stack, but that precludes having the temporary lifetime outlive the stack. (It must however be said, I'm not really a Java programmer) > Garbage collectors give you two things -- ... and (when you take pointers away) increased security. As you just said, increased security is from taking pointers away, which is completely orthogonal to GC.
- rbehrends 13y ago
  > As you just said, increased security is from taking pointers away, which is completely orthogonal to GC. That's not what he said. Removing pointer arithmetic [1] is part of getting memory safety, but not the entire story. Avoiding dangling references is another part of memory safety, and GC is one way to accomplish that; it's not orthogonal. [1] You cannot actually eliminate pointers entirely; you can disguise them, but if you want a dynamic heap and not just static memory, you need to be able to reference memory within the heap. When people talk about eliminating pointers, they generally mean unsafe C-style pointers.
  - Arelius 13y ago
    > Avoiding dangling references is another part of memory safety, and GC is one way to accomplish that; it's not orthogonal. It's the removal of the `free` and `delete` semantics that avoid dangling references. Not GC. While GC posits a good alternative to many of these problems. GC doesn't actually help memory safety at all. Unless you consider memory leaks to be a matter of "memory safety".
    - rbehrends 13y ago
      Avoiding premature free()s is precisely what garbage collection accomplishes in this context, because you will never have to call free() to avoid running out of memory.
kintamanimatt 13y ago
Correct me if I'm wrong, but I'm under the impression the JVM has a stop the world GC and uses this by default (although it does have other GCs available). I'm also under the impression that V8 and the Erlang VM, as well as the stock VMs for Ruby and Python, etc at least stop execution during the mark phase! Go has a fairly basic GC and stops execution to do its housekeeping. Yes, it's easier to write safe applications in a managed language, but it comes at a performance price due to the GC. It's far easier to write an app in C++ that performs well. There's no overhead of a virtual machine (there goes the safety...) and manual memory management tends to also yield better results in terms of footprint and CPU time when done properly. C++ gives you the tools to implement a fast process with a small memory footprint; managed languages do not unless they're using a null GC! C++ also gives you the tools tools to write a sloppy heap of shit, but then again, Java affords such a facility too!! Garbage collection simply isn't free. Maintaining the lie that a system has infinite memory comes with a price. I'm not making the point that GC is evil, and I write code in managed languages frequently, but I am making the point that it's really only appropriate for situations in which you're paying for the hardware, and using a managed language makes good business sense.
- kibwen 13y ago
  I agree with you, but I do want to point out one thing: there exists a happy medium between unsafe, no-overhead manual memory management (C++) and safe, GC'd managed memory (Java). For example, unique pointers in Rust enforce compile-time memory safety, without imposing any runtime overhead whatsoever and without forcing the programmer to manually allocate and free. In other words, there does exist such a thing as safe, no-overhead, automatic memory management, if you're willing to accept the single-ownership restriction of linear types (which in practice doesn't seem very onerous at all).

Arelius 13y ago

> What's a "stop the world GC"? I joke, of course, but I really haven't seen anything like that in a long, long time. Actually, many modern GCs are still "stop the world" including many generational GCs. the alternative generally has overhead elsewhere that hurts performance. GC has a lot of tradeoffs. > A C++ program doesn't come with an inherent advantage in memory handling. Many of the same techniques (creating and managing pools of memory) can and are being done in applications (like Cassandra) on the JVM (off-heap memory). Sure, but it sure is a lot easier in C++ since the entire infrastructure doesn't assume GC is operating. I don't even know a way to reliably allocate a temporary object in Java that won't trigger GC I could guess some things that would probably cause the optimizer to allocate it on the stack, but that precludes having the temporary lifetime outlive the stack. (It must however be said, I'm not really a Java programmer) > Garbage collectors give you two things -- ... and (when you take pointers away) increased security. As you just said, increased security is from taking pointers away, which is completely orthogonal to GC.

rbehrends 13y ago
> As you just said, increased security is from taking pointers away, which is completely orthogonal to GC. That's not what he said. Removing pointer arithmetic [1] is part of getting memory safety, but not the entire story. Avoiding dangling references is another part of memory safety, and GC is one way to accomplish that; it's not orthogonal. [1] You cannot actually eliminate pointers entirely; you can disguise them, but if you want a dynamic heap and not just static memory, you need to be able to reference memory within the heap. When people talk about eliminating pointers, they generally mean unsafe C-style pointers.
- Arelius 13y ago
  > Avoiding dangling references is another part of memory safety, and GC is one way to accomplish that; it's not orthogonal. It's the removal of the `free` and `delete` semantics that avoid dangling references. Not GC. While GC posits a good alternative to many of these problems. GC doesn't actually help memory safety at all. Unless you consider memory leaks to be a matter of "memory safety".
  - rbehrends 13y ago
    Avoiding premature free()s is precisely what garbage collection accomplishes in this context, because you will never have to call free() to avoid running out of memory.

kintamanimatt 13y ago

Correct me if I'm wrong, but I'm under the impression the JVM has a stop the world GC and uses this by default (although it does have other GCs available). I'm also under the impression that V8 and the Erlang VM, as well as the stock VMs for Ruby and Python, etc at least stop execution during the mark phase! Go has a fairly basic GC and stops execution to do its housekeeping. Yes, it's easier to write safe applications in a managed language, but it comes at a performance price due to the GC. It's far easier to write an app in C++ that performs well. There's no overhead of a virtual machine (there goes the safety...) and manual memory management tends to also yield better results in terms of footprint and CPU time when done properly. C++ gives you the tools to implement a fast process with a small memory footprint; managed languages do not unless they're using a null GC! C++ also gives you the tools tools to write a sloppy heap of shit, but then again, Java affords such a facility too!! Garbage collection simply isn't free. Maintaining the lie that a system has infinite memory comes with a price. I'm not making the point that GC is evil, and I write code in managed languages frequently, but I am making the point that it's really only appropriate for situations in which you're paying for the hardware, and using a managed language makes good business sense.

kibwen 13y ago
I agree with you, but I do want to point out one thing: there exists a happy medium between unsafe, no-overhead manual memory management (C++) and safe, GC'd managed memory (Java). For example, unique pointers in Rust enforce compile-time memory safety, without imposing any runtime overhead whatsoever and without forcing the programmer to manually allocate and free. In other words, there does exist such a thing as safe, no-overhead, automatic memory management, if you're willing to accept the single-ownership restriction of linear types (which in practice doesn't seem very onerous at all).