3 ms·

Reference counting is a form of GC, the difference being that the programmer has full control over when it runs. Most real time systems preallocate everything a

Reference counting is a form of GC, the difference being that the programmer has full control over when it runs. Most real time systems preallocate everything and never deallocate. One typical problem with GC systems is common patterns and library code cause allocations, which cause the GC to run - consuming cycles and causing jitter even if nothing is freed. (Note that even calling malloc() is non-deterministic and best avoided in real time code.)

vardump 11y ago
> Reference counting is a form of GC, the difference being that the programmer has full control over when it runs. Most real time systems preallocate everything and never deallocate. I really don't think Swift is suitable for real time embedded systems, if that's what you suggest. Even C++ is often unsuitable. Rust might have potential one day, if not already. > One typical problem with GC systems is common patterns and library code cause allocations, which cause the GC to run - consuming cycles and causing jitter even if nothing is freed. Any library code can allocate or not allocate regardless of language or memory allocation system. > (Note that even calling malloc() is non-deterministic and best avoided in real time code.) Yeah, malloc is a pretty slow thing.
kazinator 11y ago
You certainly do not have "full control" over when reference counting runs. You have some illusion of control at best. Fact is, that in a reference counting scheme, functions have to call pointer->drop() or whatever (maybe dropping a reference implicitly, thanks to smart pointers or refcounting being built into the language) all over the place, without having any idea whether that action decrements 15 to 14, or whether it decrements 1 to 0, triggering cleanup, and additional decrements on objects behind that object. You only have control in a certain well-defined circumstances, like when you have the entire lifetime of an object (or object aggregate) in the same scope, or a closely related set of scopes. In other words, in situations where you could quite probably do manual memory management (and effectively are doing that, just through the refcounting calls that you are still forced to use).
- Recurecur 11y ago
  "You certainly do not have "full control" over when reference counting runs. You have some illusion of control at best." If I use the factory pattern with pre-allocated object pools, and keep references to the objects in the factory, I have absolute certainty that ARC will never reclaim the objects. Used properly, ARC will contribute negligible overhead at runtime. "You only have control in a certain well-defined circumstances, like when you have the entire lifetime of an object (or object aggregate) in the same scope, or a closely related set of scopes. In other words, in situations where you could quite probably do manual memory management (and effectively are doing that, just through the refcounting calls that you are still forced to use)." Wrong across the board.
  - vardump 11y ago
    > If I use the factory pattern with pre-allocated object pools, and keep references to the objects in the factory, I have absolute certainty that ARC will never reclaim the objects. Used properly, ARC will contribute negligible overhead at runtime. Weird you'd say that, exactly same applies to any garbage collected language.
    - Recurecur 11y ago
      No, the GC still periodically runs, polluting cache, consuming cycles and halting the rest of the program until it's done. The only exception is if you completely avoid allocations, which is generally next to impossible in GC based languages. With ARC, there is exactly zero overhead unless a new reference is created or destroyed. In that case there's an integer add or subtract, not a global "stop the world" kind of event.

vardump 11y ago

> Reference counting is a form of GC, the difference being that the programmer has full control over when it runs. Most real time systems preallocate everything and never deallocate. I really don't think Swift is suitable for real time embedded systems, if that's what you suggest. Even C++ is often unsuitable. Rust might have potential one day, if not already. > One typical problem with GC systems is common patterns and library code cause allocations, which cause the GC to run - consuming cycles and causing jitter even if nothing is freed. Any library code can allocate or not allocate regardless of language or memory allocation system. > (Note that even calling malloc() is non-deterministic and best avoided in real time code.) Yeah, malloc is a pretty slow thing.

kazinator 11y ago

You certainly do not have "full control" over when reference counting runs. You have some illusion of control at best. Fact is, that in a reference counting scheme, functions have to call pointer->drop() or whatever (maybe dropping a reference implicitly, thanks to smart pointers or refcounting being built into the language) all over the place, without having any idea whether that action decrements 15 to 14, or whether it decrements 1 to 0, triggering cleanup, and additional decrements on objects behind that object. You only have control in a certain well-defined circumstances, like when you have the entire lifetime of an object (or object aggregate) in the same scope, or a closely related set of scopes. In other words, in situations where you could quite probably do manual memory management (and effectively are doing that, just through the refcounting calls that you are still forced to use).

Recurecur 11y ago
"You certainly do not have "full control" over when reference counting runs. You have some illusion of control at best." If I use the factory pattern with pre-allocated object pools, and keep references to the objects in the factory, I have absolute certainty that ARC will never reclaim the objects. Used properly, ARC will contribute negligible overhead at runtime. "You only have control in a certain well-defined circumstances, like when you have the entire lifetime of an object (or object aggregate) in the same scope, or a closely related set of scopes. In other words, in situations where you could quite probably do manual memory management (and effectively are doing that, just through the refcounting calls that you are still forced to use)." Wrong across the board.
- vardump 11y ago
  > If I use the factory pattern with pre-allocated object pools, and keep references to the objects in the factory, I have absolute certainty that ARC will never reclaim the objects. Used properly, ARC will contribute negligible overhead at runtime. Weird you'd say that, exactly same applies to any garbage collected language.
  - Recurecur 11y ago
    No, the GC still periodically runs, polluting cache, consuming cycles and halting the rest of the program until it's done. The only exception is if you completely avoid allocations, which is generally next to impossible in GC based languages. With ARC, there is exactly zero overhead unless a new reference is created or destroyed. In that case there's an integer add or subtract, not a global "stop the world" kind of event.