[Python-Dev] Memory bitmaps for the Python cyclic garbage collector (original) (raw)
Tim Peters tim.peters at gmail.com
Fri Sep 8 20:13:29 EDT 2017
- Previous message (by thread): [Python-Dev] Memory bitmaps for the Python cyclic garbage collector
- Next message (by thread): [Python-Dev] PEP 553 V2 - builtin breakpoint() (was Re: PEP 553: Built-in debug())
- Messages sorted by: [ date ] [ thread ] [ subject ] [ author ]
[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.
- Previous message (by thread): [Python-Dev] Memory bitmaps for the Python cyclic garbage collector
- Next message (by thread): [Python-Dev] PEP 553 V2 - builtin breakpoint() (was Re: PEP 553: Built-in debug())
- Messages sorted by: [ date ] [ thread ] [ subject ] [ author ]