-
-
Notifications
You must be signed in to change notification settings - Fork 32k
gh-133371: Don't optimize LOAD_FAST
instructions whose local is killed by DELETE_FAST
#133383
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
…_FAST` In certain cases it's possible for locals loaded by `LOAD_FAST` instructions to be on the stack when the local is killed by `DEL_FAST`. These `LOAD_FAST` instructions should not be optimized into `LOAD_FAST_BORROW` as the strong reference in the frame is killed while there is still a reference on the stack.
LOAD_FAST
instructions whose local is killed by DEL_FAST
LOAD_FAST
instructions whose local is killed by DELETE_FAST
case DELETE_FAST: { | ||
kill_local(instr_flags, &refs, oparg); | ||
break; | ||
} | ||
|
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.
FWIW: This change by itself is not enough to make the crash in test_asyncio go away.
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.
Doesn't seem to fix the test_asyncio crash.
When you're done making the requested changes, leave the comment: |
@gvanrossum - This fixes both of the repros in the linked issue. Even if this doesn't fix the original issue, it's worth merging by itself. |
@gvanrossum - I forgot to bump the magic number. I suspect that you have some cached bytecode. I've bumped the magic number, double checked that this fixes both of the repros on the linked issue, and applied this on top of the affected PR and verified that it fixes the crash in |
I have made the requested changes; please review again |
Thanks for making the requested changes! @Yhg1s, @gvanrossum, @Fidget-Spinner: please review the changes made to this pull request. |
I think the hypothesis failure is unrelated to this PR. It looks like |
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 can no longer repro the crash (probably because I am now using a different machine) but your hypothesis that I kept seeing it because of the magic number makes sense. (A little confused still -- does optimized bytecode now end up in .pyc files?)
Yes. This optimization happens statically during bytecode compilation. Maybe you are thinking of the specializing interpreter, which optimizes the compiled bytecode at runtime? |
Go ahead and merge then! |
Thanks! |
In certain cases it's possible for locals loaded by
LOAD_FAST
instructions to be on the stack when the local is killed byDELETE_FAST
. TheseLOAD_FAST
instructions should not be optimized intoLOAD_FAST_BORROW
as the strong reference in the frame is killed while there is still a reference on the stack.