[Python-ideas] Multi-core reference count garbage collection

[Jonathan Fine]

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 at gmail.com>
wrote:

> Hi Jonathan,
>
> 2018-07-19 8:33 GMT+02:00 Jonathan Fine <jfine2358 at 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
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.python.org/pipermail/python-ideas/attachments/20180719/deb6b231/attachment.html>