This issue tracker has been migrated to GitHub, and is currently read-only.
For more information, see the GitHub FAQs in the Python's Developer Guide.

Author jeremy.kloth
Recipients eric.snow, jeremy.kloth, jkloth, nanjekyejoannah, ncoghlan, vstinner
Date 2020-02-01.11:23:49
SpamBayes Score -1.0
Marked as misclassified Yes
Message-id <CAGvrs3LBh05fyS4ePw0Q99Xk0NC7TWUhfKT3emonFdPJ3FOEQw@mail.gmail.com>
In-reply-to <1580517057.49.0.13192433757.issue39511@roundup.psfhosted.org>
Content
> The problem is to make Py_INCREF/Py_DECREF efficient.

That is exactly why I didn't propose a change to them.  The singletons
still are refcounted as usual, just that their ob_refcnt is ignored.
If they somehow reach 0, they just "resurrect" themselves and ignore
the regular collection behavior.  In the presence of multiple
DECREF'ers, the ob_refcnt field is garbage, but that is OK as it is
effectively ignored.  Practicality vs Purity and all that.

> Last time someone tried to use an atomic variable for ob_refcnt, it was 20% slower if I recall correctly. If many threads start to update such atomic variable, the CPU cacheline of common singletons like None, True and False can quickly become a performance bottleneck.

Exactly so, hence why I chose the simple solution of effectively
ignoring ob_refcnt.

> On the other side, if each interpreter has its own objects, there is no need to protect ob_refcnt, the interpreter lock protects it.

My solution also does not need any protection around ob_refcnt.
History
Date User Action Args
2020-02-01 11:23:50jeremy.klothsetrecipients: + jeremy.kloth, ncoghlan, vstinner, eric.snow, nanjekyejoannah
2020-02-01 11:23:50jeremy.klothlinkissue39511 messages
2020-02-01 11:23:49jeremy.klothcreate