You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
{{ message }}
Repository navigation
Disable tracking of frozenset objects with immutables in the GC #140232
Frozenset objects with immutable objects do not need to be tracked by the GC. A similar optimization is already in place for tuples (#48938, #140204).
In particular for longer running programs with immutable frozensets this is benefical.
Why untrack eagerly, rather than lazily as we do for tuples?
Also, frozensets are not used that much, but are generated by the bytecode compiler. All compiler generated frozensets do not need tracking, so explicitly untracking them during unmarshalling might be more valuable.
I used eager untracking to prevent having to do the check in the GC for each iteration, For the tuples there is a reason it has to be done in the GC (because tuples can be generated with NULL values and filled later).
Frozensets are not used a lot indeed, but I do expect usage of immutable datasets (including the frozenset) to increase with the free-threading build being used more.
Doing the untracking during unmarshalling is not something I considered. I think the bytecode compiler generated frozensets are already handled with the approach in the PR. Correct? If adding this to the unmarshalling, do you have a pointer where this should be roughly added in the codebase?
Activity
markshannon commentedon Oct 17, 2025
Why untrack eagerly, rather than lazily as we do for tuples?
Also, frozensets are not used that much, but are generated by the bytecode compiler. All compiler generated frozensets do not need tracking, so explicitly untracking them during unmarshalling might be more valuable.
eendebakpt commentedon Oct 17, 2025
I used eager untracking to prevent having to do the check in the GC for each iteration, For the tuples there is a reason it has to be done in the GC (because tuples can be generated with NULL values and filled later).
Frozensets are not used a lot indeed, but I do expect usage of immutable datasets (including the frozenset) to increase with the free-threading build being used more.
Doing the untracking during unmarshalling is not something I considered. I think the bytecode compiler generated frozensets are already handled with the approach in the PR. Correct? If adding this to the unmarshalling, do you have a pointer where this should be roughly added in the codebase?
gh-140232: Do not track frozenset objects with immutables (#140234)
pythongh-140232: Do not track frozenset objects with immutables (pyth…