
Hi Stephan Thank you for the extract from the GC Handbook, which I think I may have seen before. Yes, it is GOOD that it's an already known idea. Searching for "buffered reference counting" I found https://mail.python.org/pipermail/python-dev/2016-October/146696.html in which Larry Hastings says that C-python "plays games with reference counts" which makes implementing "buffered reference counting" harder. And he gives examples. Larry also writes [loc cit] about resurrecting objects. I don't know what he means by this. It may be something to do with weak references. Larry's post gives some details, in which difficulties may lie. In particular, he writes === https://mail.python.org/pipermail/python-dev/2016-October/146604.html It's my contention that this API [for weak references] is simply untenable under the Gilectomy, and that it needs to change to returning a new (strong) reference. === However, I'm focused on the larger picture right now. And it good to know something of where the hazards lie. Once again, Stephan, thank you for your contribution to this thread. On Thu, Jul 19, 2018 at 9:47 AM, Stephan Houben <stephanh42@gmail.com> wrote:
Hi Jonathan,
2018-07-19 8:33 GMT+02:00 Jonathan Fine <jfine2358@gmail.com>:
I call any such scheme BUFFERED multi-core reference count garbage collection. The worker processes know nothing about how garbage collection is managed. Instead, they pass over to the GC process sufficient information to allow it to manage the garbage.
This is actually a known idea (which is GOOD, unless you wanted to apply for a patent ;-) ).
It is described, among other places, in "The Garbage Collection Handbook: The Art of Automatic Memory Management", by Richard Jones, Antony Hosking, Eliot Moss.
In fact, they also call it buffered reference counting. Section 18.2: Buffered Reference Counting: "...DeTreville[1990] had log mutators the old and new referents of each pointer update to a buffer"
By the way, this book describes a ton of other ideas to speed up reference counting in general and in the concurrent case, so it may be worthwhile to get it.
I should warn you that many of these advanced refcounting ideas have been proposed in the past already, although I am unaware of this particular technique having been implemented.
Stephan