7 ms·

One of the biggest OSes today is running nearly entirely on reference counting, so I think it's safe to say they are actually in favour.

pjmlp 7y ago
If you mean iOS, it is more a side effect of the project failure to add GC to Objective-C than anything else. Also reference counting only applies to a tiny subset of Objective-C data structures, classes derived from NSObject using Cocoa retain/release patterns. If you add Swift to the soup, there is still quite some work to do regarding performance, https://github.com/ixy-languages/ixy.swift/blob/master/performance/README.md https://github.com/ixy-languages/ixy.swift/blob/master/perfo... The other, even bigger OS, is running on tracing GCs. And Windows is running on a mix of reference counting and tracing GC.
- tomp 7y ago
  Isn’t one of the benefits of RC better (lower and more predictable) latency than with GC? Basically, you can presict when (and how much) garbage will be collected, and if it turns out that’s too much, you can fix your code... good luck doingthat with GC. The downside is, of course, that it requires much more care (to avoid cycles)
  - pjmlp 7y ago
    On single core without threading. If you add multi-threading and multi-core, there is lock contention for every single memory access to update the related counter. Additionally, if there is a big data structure in use, reaching zero will trigger a cascade deletion events reaching stop-the-world like effect. Which, depending on how the deletion was implemented, might trigger a stack overflow in very deep structures. Herb Sutter has a very interesting talk about the bad issues of reference counting and how to work around them. CppCon 2016: Herb Sutter “Leak-Freedom in C++... By Default.” https://www.youtube.com/watch?v=JfmTagWcqoE https://www.youtube.com/watch?v=JfmTagWcqoE There are multiple ways to optimize reference counting, like deferred counting, cycle collectors and a couple of others, which when you are done with all them, ends up being quite similar to having a tracing GC anyway.
    - zozbot234 7y ago
      > If you add multi-threading and multi-core, there is lock contention for every single memory access to update the related counter. You only have to update the counter when creating (or destroying) new "owning" references that might outlive any other reference to the object. This is a rare operation, and doing it potentially from multiple threads in a way that requires atomic update is even rarer. > Additionally, if there is a big data structure in use, reaching zero will trigger a cascade deletion events reaching stop-the-world like effect. This is a side effect of deterministic disposal, of course. And it only happens when freeing up large object subgraphs, not just any and all "large data structures". Yes, C++ implements reference counting in a non-ideal way. Swift is also quite bad. But one can do better.
      - pjmlp 7y ago
        When one does better it usually ends up with some form of tracing GC implementation, as per most CS research papers, it just gets to call it reference counting with optimizations to feel better.
        zozbot234 7y ago
        That's definitely true of some enhanced variations on reference counting. The changes I mentioned though do not involve any tracing of live data at runtime. (Although once one introduces the possibility of general cycles, it seems hard to avoid the requirement of tracing some live data.)
    - cesarb 7y ago
      > Additionally, if there is a big data structure in use, reaching zero will trigger a cascade deletion events reaching stop-the-world like effect. Even a deletion cascade won't stop the world: only the single thread which reached zero will be "stopped". While in tracing GC, a "stop-the-world" stops all threads, even the ones which aren't doing any allocation or deallocation at the moment.
      - zozbot234 7y ago
  - fulafel 7y ago
    People routinely profile and optimize the amount of memory churn in GC languages, and many non-RC GCs provide good telemetry about it. In RC systems you don't escape latency spikes from cascading deallocations and nondeterministic malloc/free call latencies. The malloc impl underlying RC still needs to occasionally work quite a lot to recycle freed memory, just with additional constraints compared to non-RC GCs.
- MrBuddyCasino 7y ago
  Oh wow, thanks for that link. I knew ARC was slow, I didn’t know it was THAT slow. Swift code reviewed by three programmers, no dynamic dispatch, no low-hanging fruit to optimize, and still much slower than even Golang.
- andreareina 7y ago
  Are you talking about linux? I thought the kernel used refcounting?
  - pjmlp 7y ago
    Android
- bitwize 7y ago
  Apple didn't fail to add GC. They successfully added it and then took it out again. Why? Because ARC gets you 99% of the way there while consuming less CPU and being strictly deterministic -- and the biggest Objective-C platform in the world has to run without a hitch or glitch on tiny, battery-powered devices. Adding GC to the Android platform was a stupid move. The Android UI is still janky compared to iOS, and GC is not the only reason why, but it's a significant reason. Android devices also eat battery like it's going out of style compared to iPhones and iPads. Again, GC is not the only reason for this but it factors in.
  - wbl 7y ago
    Pausless GCs are real and exist.
  - pjmlp 7y ago
    Oh they did fail indeed, Objective-C libraries were crashing left and right due to underlying C semantics and mixing frameworks compiled with and without GC enabled. So they did the only possible exit, automate the manual retain / release Cocoa patterns on the compiler, and sell a marketing story about ARC and how GC is bad. Pity that Borland and Microsoft haven't done the same about their compiler support for COM RC, done years before. Android UI is janky due to bad coding practices, specially doing too much on UI thread. Our phones are super computers compared with Lisp Machines. If you want to start counting devices sold, it is pretty clear that tracing GC has won, specially when we had any kind of device with a web browser on it.
- Someone 7y ago
  I don’t feel like investigating that, nor do I have the hardware, but I think spending ¾ of time in reference count updates is really high. https://iacoma.cs.uiuc.edu/iacoma-papers/pact18.pdf https://iacoma.cs.uiuc.edu/iacoma-papers/pact18.pdf has 42% on average, and halves that using their modification.

pjmlp 7y ago

If you mean iOS, it is more a side effect of the project failure to add GC to Objective-C than anything else. Also reference counting only applies to a tiny subset of Objective-C data structures, classes derived from NSObject using Cocoa retain/release patterns. If you add Swift to the soup, there is still quite some work to do regarding performance, https://github.com/ixy-languages/ixy.swift/blob/master/performance/README.md https://github.com/ixy-languages/ixy.swift/blob/master/perfo... The other, even bigger OS, is running on tracing GCs. And Windows is running on a mix of reference counting and tracing GC.

tomp 7y ago
Isn’t one of the benefits of RC better (lower and more predictable) latency than with GC? Basically, you can presict when (and how much) garbage will be collected, and if it turns out that’s too much, you can fix your code... good luck doingthat with GC. The downside is, of course, that it requires much more care (to avoid cycles)
- pjmlp 7y ago
  On single core without threading. If you add multi-threading and multi-core, there is lock contention for every single memory access to update the related counter. Additionally, if there is a big data structure in use, reaching zero will trigger a cascade deletion events reaching stop-the-world like effect. Which, depending on how the deletion was implemented, might trigger a stack overflow in very deep structures. Herb Sutter has a very interesting talk about the bad issues of reference counting and how to work around them. CppCon 2016: Herb Sutter “Leak-Freedom in C++... By Default.” https://www.youtube.com/watch?v=JfmTagWcqoE https://www.youtube.com/watch?v=JfmTagWcqoE There are multiple ways to optimize reference counting, like deferred counting, cycle collectors and a couple of others, which when you are done with all them, ends up being quite similar to having a tracing GC anyway.
  - zozbot234 7y ago
    > If you add multi-threading and multi-core, there is lock contention for every single memory access to update the related counter. You only have to update the counter when creating (or destroying) new "owning" references that might outlive any other reference to the object. This is a rare operation, and doing it potentially from multiple threads in a way that requires atomic update is even rarer. > Additionally, if there is a big data structure in use, reaching zero will trigger a cascade deletion events reaching stop-the-world like effect. This is a side effect of deterministic disposal, of course. And it only happens when freeing up large object subgraphs, not just any and all "large data structures". Yes, C++ implements reference counting in a non-ideal way. Swift is also quite bad. But one can do better.
    - pjmlp 7y ago
      When one does better it usually ends up with some form of tracing GC implementation, as per most CS research papers, it just gets to call it reference counting with optimizations to feel better.
      - zozbot234 7y ago
        That's definitely true of some enhanced variations on reference counting. The changes I mentioned though do not involve any tracing of live data at runtime. (Although once one introduces the possibility of general cycles, it seems hard to avoid the requirement of tracing some live data.)
  - cesarb 7y ago
    > Additionally, if there is a big data structure in use, reaching zero will trigger a cascade deletion events reaching stop-the-world like effect. Even a deletion cascade won't stop the world: only the single thread which reached zero will be "stopped". While in tracing GC, a "stop-the-world" stops all threads, even the ones which aren't doing any allocation or deallocation at the moment.
    - zozbot234 7y ago
- fulafel 7y ago
  People routinely profile and optimize the amount of memory churn in GC languages, and many non-RC GCs provide good telemetry about it. In RC systems you don't escape latency spikes from cascading deallocations and nondeterministic malloc/free call latencies. The malloc impl underlying RC still needs to occasionally work quite a lot to recycle freed memory, just with additional constraints compared to non-RC GCs.
MrBuddyCasino 7y ago
Oh wow, thanks for that link. I knew ARC was slow, I didn’t know it was THAT slow. Swift code reviewed by three programmers, no dynamic dispatch, no low-hanging fruit to optimize, and still much slower than even Golang.
andreareina 7y ago
Are you talking about linux? I thought the kernel used refcounting?
- pjmlp 7y ago
  Android
bitwize 7y ago
Apple didn't fail to add GC. They successfully added it and then took it out again. Why? Because ARC gets you 99% of the way there while consuming less CPU and being strictly deterministic -- and the biggest Objective-C platform in the world has to run without a hitch or glitch on tiny, battery-powered devices. Adding GC to the Android platform was a stupid move. The Android UI is still janky compared to iOS, and GC is not the only reason why, but it's a significant reason. Android devices also eat battery like it's going out of style compared to iPhones and iPads. Again, GC is not the only reason for this but it factors in.
- wbl 7y ago
  Pausless GCs are real and exist.
- pjmlp 7y ago
  Oh they did fail indeed, Objective-C libraries were crashing left and right due to underlying C semantics and mixing frameworks compiled with and without GC enabled. So they did the only possible exit, automate the manual retain / release Cocoa patterns on the compiler, and sell a marketing story about ARC and how GC is bad. Pity that Borland and Microsoft haven't done the same about their compiler support for COM RC, done years before. Android UI is janky due to bad coding practices, specially doing too much on UI thread. Our phones are super computers compared with Lisp Machines. If you want to start counting devices sold, it is pretty clear that tracing GC has won, specially when we had any kind of device with a web browser on it.
Someone 7y ago
I don’t feel like investigating that, nor do I have the hardware, but I think spending ¾ of time in reference count updates is really high. https://iacoma.cs.uiuc.edu/iacoma-papers/pact18.pdf https://iacoma.cs.uiuc.edu/iacoma-papers/pact18.pdf has 42% on average, and halves that using their modification.