4 ms·

You're right, I meant "with Rust's memory management story," which excludes universal reference counting. People differ on whether or not universal reference c

You're right, I meant "with Rust's memory management story," which excludes universal reference counting. People differ on whether or not universal reference counting is a form of garbage collection with weak guarantees or a form of manual memory manage with flexible semantics.

pcwalton 11y ago
> People differ on whether or not universal reference counting is a form of garbage collection with weak guarantees or a form of manual memory manage with flexible semantics. Which is pretty unfortunate, because the memory management field has always treated reference counting as a form of garbage collection—because it is [1] [2]. The idea that reference counting is somehow not GC is as far as I can tell a recent one (popularized, I think, by Cocoa and iOS?) This is not just a semantic quibble, because there are successful garbage collection techniques that combine tracing with reference counting (e.g. ulterior reference counting [3]) to achieve GC, so treating tracing as the only way to do GC makes no sense. In fact, David Bacon observed in 2004 that reference counting and tracing garbage collection are best viewed as just two extremes of a continuum [4], and many "optimizations" that you apply to one scheme or the other are really just moving the scheme you choose toward the opposite pole. [1]: http://www.memorymanagement.org/glossary/g.html#term-garbage-collection http://www.memorymanagement.org/glossary/g.html#term-garbage... [2]: http://researcher.watson.ibm.com/researcher/files/us-bacon/Bacon03Pure.pdf http://researcher.watson.ibm.com/researcher/files/us-bacon/B... [3]: http://www.cs.utexas.edu/users/mckinley/papers/urc-oopsla-2003.pdf http://www.cs.utexas.edu/users/mckinley/papers/urc-oopsla-20... [4]: https://www.cs.virginia.edu/~cs415/reading/bacon-garbage.pdf https://www.cs.virginia.edu/~cs415/reading/bacon-garbage.pdf
- jurip 11y ago
  > The idea that reference counting is somehow not GC is as far as I can tell a recent one (popularized, I think, by Cocoa and iOS?) I remember seeing lots of "but Python doesn't have REAL GC" arguments years ago. But Cocoa's foray into GC, subsequent retreat back to manual ref counting and then ARC probably have affected this too, yeah.
  - pjmlp 11y ago
    On Apple's case it is even worse in terms of urban legends, because the anti-GC crowd thinks it is some kind of victory. What they miss is that RC is a form of GC algorithms and that Apple only gave up on Objective-C's GC, because they never managed to make it stable. The way one could link GC enabled with non GC enabled frameworks, plus the fragility of underlying C code for memory management meant Apple developer forums were full of crash reports. So Apple did a "Worse is Better" pivot and basically made the compiler automate the retain/release calls from Cocoa that were being written by hand. Similarly Swift adopts ARC, because it needs to interoperate with Objective-C's runtime and having a GC would introduce extra performance issues, or force them to use a RC cache mechanism like .NET has for COM. But of course, the majority without the background knowledge of how the decision came to be or interest in compiler design, just uses Apple's decision as some kind of proof against GC.
    - pcwalton 11y ago
      I'm not really sure Apple gave up on tracing GC just because they couldn't make it stable. It also happened because they were concerned about pauses (especially when compared to Android at the time, which had a poor GC). That may or may not have been a valid concern; certainly the success of hybrid RC systems in the literature has shown that there is some merit to the idea that RC is useful to reduce pauses, though the situation is complex. The thing is, when viewed in the proper light Apple never introduced and abandoned GC. Rather, Objective-C always had GC, and the aborted "GC" attempt was actually an attempt to switch the GC algorithm.
      - pjmlp 11y ago
        I agree when discussing from the "RC is GC" CS point of view. From what I can remember pauses were never an issue. There used to exist a quite long page on the Apple Developer's web site listening all the caveats and corner cases to watch out when enabling new GC algorithm, if you will. It is called "Garbage Collection Programming Guide", but all links to it have been disabled. But you can see get it with a bit of Google-Fu. Also I remember to occasionally go through the forums and they had quite a few developers having integration issues with the new algorithm.
pjmlp 11y ago
According to the majority of CS books and papers about garbage collection, RC is yet another set of garbage collection algorithms.

pcwalton 11y ago

> People differ on whether or not universal reference counting is a form of garbage collection with weak guarantees or a form of manual memory manage with flexible semantics. Which is pretty unfortunate, because the memory management field has always treated reference counting as a form of garbage collection—because it is [1] [2]. The idea that reference counting is somehow not GC is as far as I can tell a recent one (popularized, I think, by Cocoa and iOS?) This is not just a semantic quibble, because there are successful garbage collection techniques that combine tracing with reference counting (e.g. ulterior reference counting [3]) to achieve GC, so treating tracing as the only way to do GC makes no sense. In fact, David Bacon observed in 2004 that reference counting and tracing garbage collection are best viewed as just two extremes of a continuum [4], and many "optimizations" that you apply to one scheme or the other are really just moving the scheme you choose toward the opposite pole. [1]: http://www.memorymanagement.org/glossary/g.html#term-garbage-collection http://www.memorymanagement.org/glossary/g.html#term-garbage... [2]: http://researcher.watson.ibm.com/researcher/files/us-bacon/Bacon03Pure.pdf http://researcher.watson.ibm.com/researcher/files/us-bacon/B... [3]: http://www.cs.utexas.edu/users/mckinley/papers/urc-oopsla-2003.pdf http://www.cs.utexas.edu/users/mckinley/papers/urc-oopsla-20... [4]: https://www.cs.virginia.edu/~cs415/reading/bacon-garbage.pdf https://www.cs.virginia.edu/~cs415/reading/bacon-garbage.pdf

jurip 11y ago
> The idea that reference counting is somehow not GC is as far as I can tell a recent one (popularized, I think, by Cocoa and iOS?) I remember seeing lots of "but Python doesn't have REAL GC" arguments years ago. But Cocoa's foray into GC, subsequent retreat back to manual ref counting and then ARC probably have affected this too, yeah.
- pjmlp 11y ago
  On Apple's case it is even worse in terms of urban legends, because the anti-GC crowd thinks it is some kind of victory. What they miss is that RC is a form of GC algorithms and that Apple only gave up on Objective-C's GC, because they never managed to make it stable. The way one could link GC enabled with non GC enabled frameworks, plus the fragility of underlying C code for memory management meant Apple developer forums were full of crash reports. So Apple did a "Worse is Better" pivot and basically made the compiler automate the retain/release calls from Cocoa that were being written by hand. Similarly Swift adopts ARC, because it needs to interoperate with Objective-C's runtime and having a GC would introduce extra performance issues, or force them to use a RC cache mechanism like .NET has for COM. But of course, the majority without the background knowledge of how the decision came to be or interest in compiler design, just uses Apple's decision as some kind of proof against GC.
  - pcwalton 11y ago
    I'm not really sure Apple gave up on tracing GC just because they couldn't make it stable. It also happened because they were concerned about pauses (especially when compared to Android at the time, which had a poor GC). That may or may not have been a valid concern; certainly the success of hybrid RC systems in the literature has shown that there is some merit to the idea that RC is useful to reduce pauses, though the situation is complex. The thing is, when viewed in the proper light Apple never introduced and abandoned GC. Rather, Objective-C always had GC, and the aborted "GC" attempt was actually an attempt to switch the GC algorithm.
    - pjmlp 11y ago
      I agree when discussing from the "RC is GC" CS point of view. From what I can remember pauses were never an issue. There used to exist a quite long page on the Apple Developer's web site listening all the caveats and corner cases to watch out when enabling new GC algorithm, if you will. It is called "Garbage Collection Programming Guide", but all links to it have been disabled. But you can see get it with a bit of Google-Fu. Also I remember to occasionally go through the forums and they had quite a few developers having integration issues with the new algorithm.

pjmlp 11y ago

According to the majority of CS books and papers about garbage collection, RC is yet another set of garbage collection algorithms.