-
-
Notifications
You must be signed in to change notification settings - Fork 33.6k
gh-142048: Fix quadratically increasing GC delays #142051
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 and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Conversation
|
Most changes to Python require a NEWS entry. Add one using the blurb_it web app or the blurb command-line tool. If this change has little impact on Python users, wait for a maintainer to apply the |
|
Thinking about this solution a little more, perhaps an alternative strategy that's more aligned with the original intent would be to only update the global counter to be non-negative, allowing the local ones to be negative. I'm not sure how to do that with the atomics though. I think I have a better intuition about the core bug though: the compounding happens because garbage collection first resets the global count to zero, then frees objects. Each freed object calls |
|
Most changes to Python require a NEWS entry. Add one using the blurb_it web app or the blurb command-line tool. If this change has little impact on Python users, wait for a maintainer to apply the |
Adjust allocation count handling to prevent negative values and update GC state accordingly.
|
Most changes to Python require a NEWS entry. Add one using the blurb_it web app or the blurb command-line tool. If this change has little impact on Python users, wait for a maintainer to apply the |
|
Most changes to Python require a NEWS entry. Add one using the blurb_it web app or the blurb command-line tool. If this change has little impact on Python users, wait for a maintainer to apply the |
Co-authored-by: Sam Gross <colesbury@gmail.com>
|
Most changes to Python require a NEWS entry. Add one using the blurb_it web app or the blurb command-line tool. If this change has little impact on Python users, wait for a maintainer to apply the |
|
Please add a NEWS blurb. You can either use the blurb-it webapp mentioned above or the blurb command. (I find the blurb command via |
Removed flushing of thread's local GC allocation count before thread state deletion.
colesbury
left a comment
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Thanks!
|
Thanks @kevmo314 for the PR, and @colesbury for merging it 🌮🎉.. I'm working now to backport this PR to: 3.13, 3.14. |
) The GC for the free threaded build would get slower with each collection due to effectively double counting objects freed by the GC. (cherry picked from commit eb89286) Co-authored-by: Kevin Wang <kevmo314@gmail.com>
|
Sorry, @kevmo314 and @colesbury, I could not cleanly backport this to |
|
GH-142166 is a backport of this pull request to the 3.14 branch. |
…ngh-142051) The GC for the free threaded build would get slower with each collection due to effectively double counting objects freed by the GC. (cherry picked from commit eb89286) Co-authored-by: Kevin Wang <kevmo314@gmail.com>
|
GH-142167 is a backport of this pull request to the 3.13 branch. |
This comment was marked as resolved.
This comment was marked as resolved.
|
I think the buildbot failure is unrelated. The change only affects the free threaded build and the buildbot isn't for free threaded Python. |
Fixes quadratically increasing GC delays in the free-threaded build. This is done by updating the local to global allocation count propagation to require the global count to be non-negative. This matches the existing behavior in non-free-threaded
gc.c. Additionally, adds a flush that I found was causing allocations to be lost.