-
-
Notifications
You must be signed in to change notification settings - Fork 30.5k
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
gh-111968: Use per-thread freelists for dict in free-threading #114323
Conversation
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.
I think we will want to keep the free-list state separate from the non-free-list related per-interpreter dictionary state (like watchers, and keys versions). I think the behavior would be incorrect if this were per-thread state.
Thank you for catching, there was some mistake that I didn't catch the issue :(, I will update the soon. |
Co-authored-by: Sam Gross <[email protected]>
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.
I have a suggestion about the naming of "global_dict_state", but otherwise LGTM.
#define DICT_MAX_WATCHERS 8 | ||
|
||
struct _Py_dict_state { | ||
struct _Py_global_dict_state { |
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.
Maybe _Py_dict_interp_state
?
In some places we use "global_state" to mean runtime-global (not interpreter). For example, we have:
- _dtoa_interp_state (per-interpreter)
- _mimalloc_interp_state (per-interpreter)
- _obmalloc_global_state (in PyRuntime)
Include/internal/pycore_interp.h
Outdated
@@ -41,6 +41,22 @@ struct _Py_long_state { | |||
int max_str_digits; | |||
}; | |||
|
|||
#define DICT_MAX_WATCHERS 8 | |||
|
|||
struct _Py_dict_interp_state { |
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.
@colesbury
More proper position might be pycore_dict.h but there are some header dependency issue.
So let's declare the _Py_dict_interp_state at here.
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.
Yeah, pycore_dict.h
(or pycore_dict_state.h
) seem like a better locations, but if there are technical reasons that is difficult, this does not seem like such a big deal either.
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.
The only real change is pulling the freelist out. Why can't the remainder stay in pycore_dict_state,h?
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.
It's still possible, I guess :) I will revert about it.
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!
@colesbury SInce I resolved the conflict, Can you please take a look again? cc @ericsnowcurrently |
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.
This still looks good to me. As I understand it, the plan is to address Eric's three remaining comments in subsequent PRs.
I thought "revert the PyDict_Fini() signature" was going to be done in this PR. I'm fine with doing it in a separate PR if that makes sense. |
@ericsnowcurrently |
When you're done making the requested changes, leave the comment: |
You already fixed it. 😄 |
But I like your suggestion :) That was more closer to my original intention, I updated it. |
I have made the requested changes; please review again |
FYI, I left a comment on the issue enumerating the things we punted on in this PR: #111968 (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.
LGTM
Thanks! |
--disable-gil
builds #111968