bpo-38379: don't claim objects are collected when they aren't by tim-one · Pull Request #16658 · python/cpython (original) (raw)
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service andprivacy statement. We’ll occasionally send you account related emails.
Already on GitHub?Sign in to your account
Conversation13 Commits6 Checks0 Files changed
Conversation
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.Learn more about bidirectional Unicode characters
[ Show hidden characters]({{ revealButtonHref }})
nothing is actually collected in this run of gc. Change the stats to relect that truth.
LGTM. I don't think the performance impact is significant either and the stats are wrong without this fix.
I don't think the performance impact is significant either
There is no performance hit here - that would come with the second half of the bpo suggestions, if gc were taught how to keep on collecting despite that a finalizer resurrected some trash. As is (with or without this PR so far), gc gives up after detecting a resurrection. Which leads to the test case on the bpo issue, where trash keeps on building up forever and gc never make progress.
@tim-one: Please replace # with GH- in the commit message next time. Thanks!
Thanks @tim-one for the PR 🌮🎉.. I'm working now to backport this PR to: 3.7, 3.8.
🐍🍒⛏🤖
I'm having trouble backporting to 3.8. Reason: 'Error 110 while writing to socket. Connection timed out.'. Please retry by removing and re-adding the needs backport to 3.8 label.
Sorry, @tim-one, I could not cleanly backport this to 3.7 due to a conflict.
Please backport using cherry_picker on command line.cherry_picker ecbf35f9335b0420cb8adfda6f299d6747a16515 3.7
Thanks @tim-one for the PR 🌮🎉.. I'm working now to backport this PR to: 3.8.
🐍🍒⛏🤖
Sorry @tim-one, I had trouble checking out the 3.8 backport branch.
Please backport using cherry_picker on command line.cherry_picker ecbf35f9335b0420cb8adfda6f299d6747a16515 3.8
I have no idea how to backport this (well - or anything else). I installed cherry_picker and ran the suggested commands, but even in --dry-run mode they blow up with stuff like
subprocess.CalledProcessError: Command '['git', 'log', '-r', 'ecbf35f']' returned non-zero exit status 128.
So I'm giving up before I do real harm ☹️
pablogsal pushed a commit to pablogsal/cpython that referenced this pull request
- bpo-38379: when a finalizer resurrects an object, nothing is actually collected in this run of gc. Change the stats to relect that truth. (cherry picked from commit ecbf35f)
Co-authored-by: Tim Peters tim.peters@gmail.com
pablogsal pushed a commit to pablogsal/cpython that referenced this pull request
- bpo-38379: when a finalizer resurrects an object, nothing is actually collected in this run of gc. Change the stats to relect that truth.. (cherry picked from commit ecbf35f)
Co-authored-by: Tim Peters tim.peters@gmail.com
jacobneiltaylor pushed a commit to jacobneiltaylor/cpython that referenced this pull request
- bpo-38379: when a finalizer resurrects an object, nothing is actually collected in this run of gc. Change the stats to relect that truth.