RetroSearch Browse

Fri Sep 8 20:13:29 EDT 2017 · https://mail.python.org/pipermail/python-dev/2017-September/149413.html

[Tim]
>> In that case, it's because Python
>> _does_ mutate the objects' refcount members under the covers, and so
>> the OS ends up making fresh copies of the memory anyway.

[Greg Ewing <greg.ewing at canterbury.ac.nz>]
> Has anyone ever considered addressing that by moving the
> refcounts out of the objects and keeping them somewhere
> else?

Not that I know of.  I know Larry Hastings was considering doing it as
part of his experiments with removing the GIL, but that had nothing to
do with reducing cross-process copy-on-write surprises (it had to do
with "batching" refcount operations to eliminate a need for
fine-grained locking).

As-is, I'd say it's "a feature" that the refcount is part of the
object header.  Ref count manipulations are very frequent, and as part
of the object header a refcount tends to show up in cache lines "for
free" as a side effect of accessing the object's type pointer.

Home - News ( United States | United Kingdom | Italy | Germany ) - Football scores

Showing content from https://mail.python.org/pipermail/python-dev/2017-September/149413.html below:

[Python-Dev] Memory bitmaps for the Python cyclic garbage collector