6 ms·

Exactly zero pauses only exist if you never free memory, which for most purposes is not an option. In most languages, freeing all all the heap-allocated objects

Exactly zero pauses only exist if you never free memory, which for most purposes is not an option. In most languages, freeing all all the heap-allocated objects of a big array will take longer than in a language with GC. The reason pauses tend to be bigger in a GCed language is because all the freeing is being done at once, instead of every single time an object is determined to no longer be needed. In any case, the tradeoff you're making is that you have deal with memory. Even in a language like Rust, you need to care about references, ownership, struct vs heap and possibly even reference counting. You might even be bitten by "running out of memory" due to memory defragmentation. In most cases, you don't need to care about these things in a GC'ed language, at the expense of larger memory usage and possibly noticable pauses.

nyanpasu64 5y ago
I can write (and am in fact developing right now) a music app in a non-GC language, with a real-time audio thread which (unless faced with unusual inputs like hundreds of simultaneous events) performs zero allocations or deallocations after initial startup. It acquires and releases all heap allocations from a wait-free queue between the audio thread and GUI thread. If I were to port the app to C#, I have no way of telling the C# GC to never pause the audio thread, and to only pause the GUI thread. I'm not sure if it's possible for a tracing GC to coexist with a never-paused thread which owns manually memory-managed types, and for the two threads to exchange manually freed or GC'd objects without FFI boilerplate, serialization, or copying. If it exists (and there's a GUI framework written in the GC portion of the language), let me know! Admittedly manual memory management does mean a lot more things to worry about (ranging from manual memory management to lock-free wait-free programming) Personally I find deterministic lifetimes and single ownership which can be moved/swapped to be elegant. However, Qt's QObject system combines the practical disadvantages of manual freeing (having to track complex semantics in your head, and check whether each method call transfers ownership or not, with leaks or use-after-free if you get it wrong) with the inelegance of GC (pervasive aliasing and mutability, unclear ownership, a magical runtime-like system).
- Skinney 5y ago
  Sure, and in your specific use case, the tradeoff of dealing with memory seems worth it. My point was that there are tradeoffs, which you admit. The comment i responded to indicated that there wasn’t one.
- kaba0 5y ago
  I agree that your specific use-case is indeed good reason for manually managed memory, but theoretically, I don’t see anything inherent in specifying GC on a per-thread basis. Like, perhaps one could set a property on a new Thread object and set GC to false - that would probably allow your program to function even in a managed environment.
  - ncmncm 5y ago
    Not using GC does not, in fact, imply "manually managed memory". Manually managed memory is the only thing possible in C, but C is not the only non-GC language. The most commonly used non-GC languages provide other mechanisms, and usual practice in them is to rely on their non-GC, automated memory management.
    - kaba0 5y ago
      Do you mean RAII and rust’s ownership model? It still has very similar tradeoffs to manual memory management, they are just much less error prone. But the fundamental thing is that you still have to think about memory, memory layout will have to be considered during refactors, etc.
      - ncmncm 5y ago
        If you are not thinking about memory, or memory layout, you are not programming. Anyway, not programming well. And "tradeoffs" is a misleading term to apply to a process that does not involve giving up anything in exchange for the benefit of pause-free, fully predictable operation.
        5y ago
saagarjha 5y ago
Of course, certain applications do indeed never allocate once they have started up.
- ncmncm 5y ago
  Indeed, that is a very common practice, where latency matters. You might have a great deal of memory heap activity in the first second, and then hardly any for months after.
zozbot234 5y ago
> In most cases, you don't need to care about these things in a GC'ed language, at the expense of larger memory usage and possibly noticable pauses. GC has other drawbacks as well. The whole tracing workload (which still exists even in low-latency, concurrent GC's) messes up your locality of references and interacts badly with CPU- and OS-level caching and memory management. Plus the mutator part of your program is heavily constrained in how it can layout objects in memory, since the tracing GC must be enabled to select references to other objects unambiguously. It's a non-trivial drain on performance on memory-bandwidth limited workloads, which tends to be most of them these days. Reference counting does away with most of these issues, and gives you deterministic finalization of all resources not just memory. Alternately, you can selectively use arenas to defer the freeing of some objects, while still being deterministic elsewhere.
- ncmncm 5y ago
  zozbot has it right. Reference counting is a form of GC to use when performance doesn't matter. Performance never matters except where it does. But automated memory management without reference counting is usual practice in a modern non-GC language. Freeing an array of objects only involves a series of calls to a deallocator when the array elements have pointers in them. That is typically unavoidable in Java, but not in non-GC languages. Arena allocation, where memory in a subsystem is allocated using a specific allocator object, deallocation there is an in-line no-op, and all of subsystem memory is reclaimed en bloc at a chosen event boundary, is a common alternative where more control is needed. It is still not "manual memory management"; memory for objects is managed invisibly, and still without reference counting. The usual advertising for GC is that it means you don't need to think about managing memory. The actual experience is that, where it matters at all, you have to think about it a great deal more.
yakubin 5y ago
> In most languages, freeing all all the heap-allocated objects of a big array will take longer than in a language with GC. Only if elements of the array are separately allocated (boxed) or have destructors.
- Skinney 5y ago
  And if the array is heap allocated.
  - yakubin 5y ago
    If the array is stack-allocated and the elements are boxed (i.e. heap-allocated) or have destructors, you are still going to need to call the destructors or the free on the elements when the array goes out of scope.
    - ncmncm 5y ago
      Such a layout, and all it costs, is typically unavoidable in GC languages, and usually easily avoided in non-GC languages, particularly in cases where it would matter. Thus, it is incorrect to talk about multiple calls to a deallocator. You get just one for the whole array.
    - Skinney 5y ago
      My point was: it still takes longer time to de-allocate a large array even if the only thing that needs to be freed is the array itself, when compared to a GC. GC never needs to free anything, it instead overwrites garbage memory with live memory.

nyanpasu64 5y ago

I can write (and am in fact developing right now) a music app in a non-GC language, with a real-time audio thread which (unless faced with unusual inputs like hundreds of simultaneous events) performs zero allocations or deallocations after initial startup. It acquires and releases all heap allocations from a wait-free queue between the audio thread and GUI thread. If I were to port the app to C#, I have no way of telling the C# GC to never pause the audio thread, and to only pause the GUI thread. I'm not sure if it's possible for a tracing GC to coexist with a never-paused thread which owns manually memory-managed types, and for the two threads to exchange manually freed or GC'd objects without FFI boilerplate, serialization, or copying. If it exists (and there's a GUI framework written in the GC portion of the language), let me know! Admittedly manual memory management does mean a lot more things to worry about (ranging from manual memory management to lock-free wait-free programming) Personally I find deterministic lifetimes and single ownership which can be moved/swapped to be elegant. However, Qt's QObject system combines the practical disadvantages of manual freeing (having to track complex semantics in your head, and check whether each method call transfers ownership or not, with leaks or use-after-free if you get it wrong) with the inelegance of GC (pervasive aliasing and mutability, unclear ownership, a magical runtime-like system).

Skinney 5y ago
Sure, and in your specific use case, the tradeoff of dealing with memory seems worth it. My point was that there are tradeoffs, which you admit. The comment i responded to indicated that there wasn’t one.
kaba0 5y ago
I agree that your specific use-case is indeed good reason for manually managed memory, but theoretically, I don’t see anything inherent in specifying GC on a per-thread basis. Like, perhaps one could set a property on a new Thread object and set GC to false - that would probably allow your program to function even in a managed environment.
- ncmncm 5y ago
  Not using GC does not, in fact, imply "manually managed memory". Manually managed memory is the only thing possible in C, but C is not the only non-GC language. The most commonly used non-GC languages provide other mechanisms, and usual practice in them is to rely on their non-GC, automated memory management.
  - kaba0 5y ago
    Do you mean RAII and rust’s ownership model? It still has very similar tradeoffs to manual memory management, they are just much less error prone. But the fundamental thing is that you still have to think about memory, memory layout will have to be considered during refactors, etc.
    - ncmncm 5y ago
      If you are not thinking about memory, or memory layout, you are not programming. Anyway, not programming well. And "tradeoffs" is a misleading term to apply to a process that does not involve giving up anything in exchange for the benefit of pause-free, fully predictable operation.
      - 5y ago

saagarjha 5y ago

Of course, certain applications do indeed never allocate once they have started up.

ncmncm 5y ago
Indeed, that is a very common practice, where latency matters. You might have a great deal of memory heap activity in the first second, and then hardly any for months after.

zozbot234 5y ago

> In most cases, you don't need to care about these things in a GC'ed language, at the expense of larger memory usage and possibly noticable pauses. GC has other drawbacks as well. The whole tracing workload (which still exists even in low-latency, concurrent GC's) messes up your locality of references and interacts badly with CPU- and OS-level caching and memory management. Plus the mutator part of your program is heavily constrained in how it can layout objects in memory, since the tracing GC must be enabled to select references to other objects unambiguously. It's a non-trivial drain on performance on memory-bandwidth limited workloads, which tends to be most of them these days. Reference counting does away with most of these issues, and gives you deterministic finalization of all resources not just memory. Alternately, you can selectively use arenas to defer the freeing of some objects, while still being deterministic elsewhere.

ncmncm 5y ago
zozbot has it right. Reference counting is a form of GC to use when performance doesn't matter. Performance never matters except where it does. But automated memory management without reference counting is usual practice in a modern non-GC language. Freeing an array of objects only involves a series of calls to a deallocator when the array elements have pointers in them. That is typically unavoidable in Java, but not in non-GC languages. Arena allocation, where memory in a subsystem is allocated using a specific allocator object, deallocation there is an in-line no-op, and all of subsystem memory is reclaimed en bloc at a chosen event boundary, is a common alternative where more control is needed. It is still not "manual memory management"; memory for objects is managed invisibly, and still without reference counting. The usual advertising for GC is that it means you don't need to think about managing memory. The actual experience is that, where it matters at all, you have to think about it a great deal more.

yakubin 5y ago

> In most languages, freeing all all the heap-allocated objects of a big array will take longer than in a language with GC. Only if elements of the array are separately allocated (boxed) or have destructors.

Skinney 5y ago
And if the array is heap allocated.
- yakubin 5y ago
  If the array is stack-allocated and the elements are boxed (i.e. heap-allocated) or have destructors, you are still going to need to call the destructors or the free on the elements when the array goes out of scope.
  - ncmncm 5y ago
    Such a layout, and all it costs, is typically unavoidable in GC languages, and usually easily avoided in non-GC languages, particularly in cases where it would matter. Thus, it is incorrect to talk about multiple calls to a deallocator. You get just one for the whole array.
  - Skinney 5y ago
    My point was: it still takes longer time to de-allocate a large array even if the only thing that needs to be freed is the array itself, when compared to a GC. GC never needs to free anything, it instead overwrites garbage memory with live memory.