PEP 683: Immortal Objects - A new approach for memory managing
summary
PEP 683 makes some Python objects truly persistent by setting their C reference count to a very large sentinel so increments/decrements skip them; implemented in C and already used at Instagram to keep many shared constants resident across forked workers, which lowers process memory growth while handling millions of requests. Measurements show roughly 2% CPU overhead in the demo, some related PEPs predict 5–8% on other configs. Examples marked immortal include small integers and empty strings, they only free at process exit and cannot be created from pure Python today.
AI-written summary · about
chapters (13)
- 0:00Introduction and speaker background
- 1:12Talk overview and schedule
- 1:56Python objects and reference counting
- 6:55Memory leaks in threads and processes
- 7:17Motivation for PEP 683
- 11:36Copy-on-write issues in server architecture
- 15:15What are immortal objects?
- 18:24Implementation challenges and solutions
- 20:10Future uses of immortal objects
- 21:13PEP 684 and sub-interpreters
- 22:57PEP 730 making GIL optional
- 24:43Performance impact and compatibility
- 25:26Q&A session
related talks
29mPEP 683: Immortal Objects - A new approach for memory managing
31mIntroducing Immortal Objects: Building Block Towards a Multi-core Python Runtime
23mMemoirs of a Python Object: Memory Management and Improving Performance
19mDynamically Checked Deep Immutability in Python
26mPython Performance at Scale - Making Python Faster at Instagram
01h 18mPython 103: Mmmm... Understanding Python's Memory Model, Mutability, and Methods
01h 32mPyErlang -- a stepping stone towards behaviour-oriented concurrency in Python
01h 18mPython 103: Mmmm... Understanding Python's Memory Model, Mutability, and Methods