René's URL Explorer Experiment

{"@context":"https://schema.org","@type":"DiscussionForumPosting","headline":"Temporarily immortalize objects that use deferred reference counting","articleBody":"# Feature or enhancement\n\nWork is ongoing to implement [deferred reference counting](https://peps.python.org/pep-0703/#deferred-reference-counting) in the free-threaded build. The goal is to avoid many of the scaling bottlenecks caused by reference count contention. However, the work is complex and may not be finished in time for the 3.13 beta release and feature freeze.\n\nIn the meantime, we should temporarily immortalize objects that would use deferred reference counting in order to avoid bottlenecks that would inhibit scaling.\n\nThis has some real downsides: objects that are immortalized are never collected so an application that repeatedly creates many of these objects will leak memory. I think the trade-off is still worth it: if we can't scale multithreaded programs, then the free-threaded build is not particularly useful.\n\nOnce we implement deferred reference counting, we will get rid of this.\n\n### What types of objects use deferred reference counting?\n\n* Top-level functions\n* Descriptors\n* Modules and their dictionaries\n* Heap types\n* Code objects\n\n### Refleak buildbots\n\nWe want the free-threading refleak buildbots to continue to work and catch leaks. In order to do that, we'll want to:\n\n1) Only do the deferred -\u003e immortal conversion when the first non-main thread is started\n2) Disable the conversion at runtime in the refleak tests via an internal API\n\n\n\n\u003c!-- gh-linked-prs --\u003e\n### Linked PRs\n* gh-118112\n\u003c!-- /gh-linked-prs --\u003e\n","author":{"url":"https://github.com/colesbury","@type":"Person","name":"colesbury"},"datePublished":"2024-04-11T21:45:26.000Z","interactionStatistic":{"@type":"InteractionCounter","interactionType":"https://schema.org/CommentAction","userInteractionCount":2},"url":"https://github.com/117783/cpython/issues/117783"}