4 ms·

Their notion of "better" may differ from yours. Do you actually know people who claim that reference counting is faster than a marking GC? Reference counting c

Their notion of "better" may differ from yours. Do you actually know people who claim that reference counting is faster than a marking GC? Reference counting can be better in terms of ease of implementation, cross-language interoperability, and by reclaiming memory immediately when the last reference to it disappears.

pjmlp 8y ago
Reference counting is only better in terms of ease of implementation. Hence why it is usually one of the earliest chapters in any CS book about GC algorithms. Reclaiming memory immediatly only works in simple data structures. Naive reference counting impletations have similar stop-the-world effects when releasing relatively big data structures, which can even lead to stack overflows, if the destructor calls happen to be nested. In case of Objective-C and Swift, Objective-C tracing GC project failed due to the underlying C semantics, thus they took the 2nd best approach of enforcing Cocoa retain/release patterns via the compiler, which only applies to a small set of Objective-C data types. Swift naturally had to support the same memory management model, as means to keep compatibility with the Objective-C runtime.
- zozbot123 8y ago
  If you don't need to "reclaim memory immediately", you can often use arenas, a.k.a. regions - freeing an arena does not incur a "stop the world" pause. Similarly, most "big data structures" have little use for reference counting in their internals (albeit concurrent data structures may indeed use refcounting internally, and more obviously it comes up when implementing general graph structures). Overall, outside of the use of obligate GC as in Swift, I suspect that nested destructor calls are unlikely to be a significant problem in practice.
  - pjmlp 8y ago
    Regions are a feature also available in languages with tracing GC, while offering better productivity in overall.
- vlovich123 8y ago
  Eh. In practice reference counting solves 90% of the problem and keeps memory usage low at all times. It's part of why Java programs are so hard to tune for performance & end up eating so much RAM. If you don't believe, compare Android & iOS where even though Android has enormous financial & competitive pressure to improve the performance they still end up requiring 2x the amount of RAM that iOS does which is partially driven by the choice of Java.
  - pjmlp 8y ago
    People keep referring to Java to talk bad about tracing GCs. The fact is that Java isn't the only game in town, and all GC enabled system programming languages do offer multiple ways to manage memory. Value types, traced GC memory references, global memory allocation, stack values, RAII, untraced memory references in unsafe code blocks. Not every OOP language is Java, nor every GC is Java's GC. Additionally, not every Java GC is like OpenJDK GC's, there are plenty to chose from, including soft real time ones for embedded deployments. As for Android, it is a fork still catching up with what Java toolchains like PTC/Aonix are capable of, all because Google decided it could do better while screwing Sun in the process.
    - zozbot123 8y ago
      > and all GC enabled system programming languages do offer multiple ways to manage memory. Since "GC-enabled system programming languages" is an oxymoron, a claim about what such languages may or may not include is just not very useful. But it's definitely the case that properly combining, e.g. "traced GC memory references" and RAII including deterministic deallocation for resources is still a matter of ongoing research, e.g. https://arxiv.org/abs/1803.02796 https://arxiv.org/abs/1803.02796 That may or may not pan out in the future, as may other things such as pluggable, lightweight GC for a subset of memory objects, etc., but let's stop putting lipstick on the pig that is obligate tracing GC.
      - pjmlp 8y ago
        An oxymoron only in the minds of anti-tracing GC hate crowd. - Mesa/Cedar at Xerox PARC - Algol 68 at UK Navy computing center - Modula-2+ at Olivetti DEC - Modula-3 at Olivetti DEC/Compaq/HP and University of Washington - Oberon, Oberon-2, Active Oberon, Oberon-07 at ETHZ - Oberon-07 at Astrobe - Component Pascal at Oberon microsystems AG - Sing#, Dafny and System C# (M#) at Microsoft Research - Java when running AOT compiled on bare metal embedded systems like PTC Perc and Aicas Jamaica - D by Digital Mars - Go at Google (Fuchsia) and MIT (Biscuit) Lets stop pretending reference counting is the best of all GC algorithms, in spite the fact that is quite basic and does not scale in modern multi-core NUMA architectures.
- MaxBarraclough 8y ago
  > Reference counting is only better in terms of ease of implementation. That sounds unduly broad. You really think the Linux kernel would be better off using a GC?

pjmlp 8y ago

Reference counting is only better in terms of ease of implementation. Hence why it is usually one of the earliest chapters in any CS book about GC algorithms. Reclaiming memory immediatly only works in simple data structures. Naive reference counting impletations have similar stop-the-world effects when releasing relatively big data structures, which can even lead to stack overflows, if the destructor calls happen to be nested. In case of Objective-C and Swift, Objective-C tracing GC project failed due to the underlying C semantics, thus they took the 2nd best approach of enforcing Cocoa retain/release patterns via the compiler, which only applies to a small set of Objective-C data types. Swift naturally had to support the same memory management model, as means to keep compatibility with the Objective-C runtime.

zozbot123 8y ago
If you don't need to "reclaim memory immediately", you can often use arenas, a.k.a. regions - freeing an arena does not incur a "stop the world" pause. Similarly, most "big data structures" have little use for reference counting in their internals (albeit concurrent data structures may indeed use refcounting internally, and more obviously it comes up when implementing general graph structures). Overall, outside of the use of obligate GC as in Swift, I suspect that nested destructor calls are unlikely to be a significant problem in practice.
- pjmlp 8y ago
  Regions are a feature also available in languages with tracing GC, while offering better productivity in overall.
vlovich123 8y ago
Eh. In practice reference counting solves 90% of the problem and keeps memory usage low at all times. It's part of why Java programs are so hard to tune for performance & end up eating so much RAM. If you don't believe, compare Android & iOS where even though Android has enormous financial & competitive pressure to improve the performance they still end up requiring 2x the amount of RAM that iOS does which is partially driven by the choice of Java.
- pjmlp 8y ago
  People keep referring to Java to talk bad about tracing GCs. The fact is that Java isn't the only game in town, and all GC enabled system programming languages do offer multiple ways to manage memory. Value types, traced GC memory references, global memory allocation, stack values, RAII, untraced memory references in unsafe code blocks. Not every OOP language is Java, nor every GC is Java's GC. Additionally, not every Java GC is like OpenJDK GC's, there are plenty to chose from, including soft real time ones for embedded deployments. As for Android, it is a fork still catching up with what Java toolchains like PTC/Aonix are capable of, all because Google decided it could do better while screwing Sun in the process.
  - zozbot123 8y ago
    > and all GC enabled system programming languages do offer multiple ways to manage memory. Since "GC-enabled system programming languages" is an oxymoron, a claim about what such languages may or may not include is just not very useful. But it's definitely the case that properly combining, e.g. "traced GC memory references" and RAII including deterministic deallocation for resources is still a matter of ongoing research, e.g. https://arxiv.org/abs/1803.02796 https://arxiv.org/abs/1803.02796 That may or may not pan out in the future, as may other things such as pluggable, lightweight GC for a subset of memory objects, etc., but let's stop putting lipstick on the pig that is obligate tracing GC.
    - pjmlp 8y ago
      An oxymoron only in the minds of anti-tracing GC hate crowd. - Mesa/Cedar at Xerox PARC - Algol 68 at UK Navy computing center - Modula-2+ at Olivetti DEC - Modula-3 at Olivetti DEC/Compaq/HP and University of Washington - Oberon, Oberon-2, Active Oberon, Oberon-07 at ETHZ - Oberon-07 at Astrobe - Component Pascal at Oberon microsystems AG - Sing#, Dafny and System C# (M#) at Microsoft Research - Java when running AOT compiled on bare metal embedded systems like PTC Perc and Aicas Jamaica - D by Digital Mars - Go at Google (Fuchsia) and MIT (Biscuit) Lets stop pretending reference counting is the best of all GC algorithms, in spite the fact that is quite basic and does not scale in modern multi-core NUMA architectures.
MaxBarraclough 8y ago
> Reference counting is only better in terms of ease of implementation. That sounds unduly broad. You really think the Linux kernel would be better off using a GC?