Introducing Immortal Objects: Building Block Towards a Multi-core Python Runtime
summary
Explains PEP 683’s concrete change: marking a small set of long-lived objects as immortal by setting a magic refcount 4294967295 (low 32 bits on 64-bit), changing Py_INCREF/Py_DECREF and related APIs to no-op for those objects and stopping runtime mutations of the GC header. Demonstrates edits against CPython 3.12 sources, shows why this avoids CAS-induced cache invalidation, data races and copy‑on‑write growth (Instagram’s memory profile case), and notes immortal objects are reclaimed only at finalization.
AI-written summary · about
chapters (12)
- 0:00Immortal objects in Python
- 1:12Python objects and memory basics
- 4:31Reference counting and GC
- 9:56Object lifecycle and mutability
- 13:46Immutable objects aren't truly
- 15:56PEP 683 immortal objects
- 19:38Motivations for multicore Python
- 22:06CPU cache invalidation and races
- 24:38Avoiding copy-on-write
- 27:27Memory usage impact
- 28:55PEP 683 specification details
- 30:21Conclusion and Q&A
related talks
35mPEP 683: Immortal Objects - A new approach for memory managing
29mPEP 683: Immortal Objects - A new approach for memory managing
19mDynamically Checked Deep Immutability in Python
23mMemoirs of a Python Object: Memory Management and Improving Performance
01h 18mPython 103: Mmmm... Understanding Python's Memory Model, Mutability, and Methods
01h 18mPython 103: Mmmm... Understanding Python's Memory Model, Mutability, and Methods
25mIs it me or Python memory management? 🤔💻
27mDemystifying Python’s Generational Garbage Collector