3 ms·

As the article says, reference counting was not the problem. They got their improvements by disabling the garbage collector sweeps, but reference counting was s

As the article says, reference counting was not the problem. They got their improvements by disabling the garbage collector sweeps, but reference counting was still being used.

vincent-manis 6y ago
My point was that CPython does reference counting, resulting in the Copy-On-Read behavior described in the article. That isn't something that can be easily changed, not without writing a whole new CPython system (or switching to another Python implementation). Their solution to the problem was the cleanest, under the circumstances.
- KMag 6y ago
  Most tracing GC solutions would run into the same problem. A common implementation strategy of the classic three-color collector puts the grey bit in the object header (and often also the white/black bit). A two finger (Cheney-style) collector avoids an explicit grey bit, but moves objects around, which also triggers CoW of shared pages. If you want CoW-friendly GC, you need to move your color bits / reference counts to be all together in the headers of your GC arenas instead of being in the object headers. That way, your high mutation bits are all together in a small number of pages. Those pages with the color bits/counters end up not being shared across processes, but at least they're all packed together to minimize the number of affected pages.
- wzdd 6y ago
  The article goes on to point out that their theory about copy-on-read being the problem didn't pan out, because when they disabled refcounting on code objects shared memory usage didn't change. It then goes on to identify the real culprit, which was GC. So, no, this article is not an excellent argument against reference counting.
- CyberDildonics 6y ago
  Copy on read doesn't even make sense, since a copy is a read. Most problems people ascribe to reference counting have way more to do with excessive memory allocation and instead of fixing that problem and getting massive speedups of 7x or more, people try to fiddle with memory management schemes to gain 5% here or there at the expense of large unpredictable pauses.

As the article says, reference counting was not the problem. They got their improvements by disabling the garbage collector sweeps, but reference counting was still being used.

vincent-manis 6y ago

My point was that CPython does reference counting, resulting in the Copy-On-Read behavior described in the article. That isn't something that can be easily changed, not without writing a whole new CPython system (or switching to another Python implementation). Their solution to the problem was the cleanest, under the circumstances.

KMag 6y ago
Most tracing GC solutions would run into the same problem. A common implementation strategy of the classic three-color collector puts the grey bit in the object header (and often also the white/black bit). A two finger (Cheney-style) collector avoids an explicit grey bit, but moves objects around, which also triggers CoW of shared pages. If you want CoW-friendly GC, you need to move your color bits / reference counts to be all together in the headers of your GC arenas instead of being in the object headers. That way, your high mutation bits are all together in a small number of pages. Those pages with the color bits/counters end up not being shared across processes, but at least they're all packed together to minimize the number of affected pages.
wzdd 6y ago
The article goes on to point out that their theory about copy-on-read being the problem didn't pan out, because when they disabled refcounting on code objects shared memory usage didn't change. It then goes on to identify the real culprit, which was GC. So, no, this article is not an excellent argument against reference counting.
CyberDildonics 6y ago
Copy on read doesn't even make sense, since a copy is a read. Most problems people ascribe to reference counting have way more to do with excessive memory allocation and instead of fixing that problem and getting massive speedups of 7x or more, people try to fiddle with memory management schemes to gain 5% here or there at the expense of large unpredictable pauses.