[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.ew...@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. _______________________________________________ Python-Dev mailing list Python-Dev@python.org https://mail.python.org/mailman/listinfo/python-dev Unsubscribe: https://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
