Skip to content
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

bpo-45256: Don't track the exact depth of each InterpreterFrame #30372

Merged
merged 7 commits into from
Jan 5, 2022

Conversation

brandtbucher
Copy link
Member

@brandtbucher brandtbucher commented Jan 3, 2022

We only really care whether or not an exiting frame is the "root" of the current CFrame, which a boolean value can track more efficiently.

(In fact, the current code is buggy, and doesn't even maintain frame->depth correctly... it's only ever set to 0 or 1 anyways!)

https://bugs.python.org/issue45256

Copy link
Member

@pablogsal pablogsal left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

LGTM

@@ -44,7 +46,7 @@ typedef struct _interpreter_frame {
int f_lasti; /* Last instruction if called */
int stacktop; /* Offset of TOS from localsplus */
PyFrameState f_state; /* What state the frame is in */
int depth; /* Depth of the frame in a ceval loop */
bool own_cframe; // Whether this is the "root" frame for the current CFrame
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I'm not sure about this name.

I don't think the frame really owns the C frame. Also, be wary of using CFrame, as CFrame is a struct name.
If I were to suggest a name, it would be is_entry as this is the entry InterpreterFrame for _PyEval_EvalFrameDefault.
If you think ownership is a better mental model, then owns_cframe is fine.

Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

@markshannon Can it be named backed_by_cframe or cframe_backed instead?

Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

This has nothing to do with how the data is stored.

Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I agree with Mark, I think it should be called entry_frame or something similar. Reasoning about ownership is a bit more obscure in my opinion

Copy link
Member Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I was hoping somebody would suggest a better name! is_entry it is...

@@ -101,7 +103,7 @@ _PyFrame_InitializeSpecials(
frame->generator = NULL;
frame->f_lasti = -1;
frame->f_state = FRAME_CREATED;
frame->depth = 0;
frame->own_cframe = true;
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

This should default to false. Then it only need be set at the start of _PyEval_EvalFrameDefault, not for every internal call.

Copy link
Member

@markshannon markshannon left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

A couple of minor issues, but sound in general.

@bedevere-bot
Copy link

When you're done making the requested changes, leave the comment: I have made the requested changes; please review again.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
Development

Successfully merging this pull request may close these issues.

6 participants