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

Store both function and code object in the function version cache #665

Open
gvanrossum opened this issue Mar 17, 2024 · 3 comments
Open
Assignees

Comments

@gvanrossum
Copy link
Collaborator

The idea here is to avoid function version cache misses for generator expressions. (See #664 (comment).)

We have a complicated mechanism to reset the function version whenever __code__, __defaults__ and a few other function attributes are mutated. (BTW: nothing is affected by changes to __annotations__, and yet that is also considered a mutation.)

Why not instead just reset the function version to zero and stick to that? We then guarantee that the function version is either zero or matches the code object version.

Nothing changes for specialization except that _PyFunction_GetVersionForCurrentState() returns 0 for mutated functions. This is unlikely to affect any benchmark or other perf-critical real-world code.

The function version cache would double in size, and store both the function and the code object. When a function is deallocated or its version is reset to zero, it evicts itself from the cache, but keeps the code object. Code objects remove themselves from the cache when deallocated (and probably also evict the function object).

For Tier 2, when generating _PUSH_FRAME or _POP_FRAME, we can handle the case where the function version maps to a pair (NULL, some_code_object) -- we store NULL in the operand, but we use some_code_object to trace through. Globals removal will no longer work (boo hoo), but at least we still have a trace. Presumably at least some generator expressions don't use globals (they can still use builtins, which can be reached without the function object).

@gvanrossum
Copy link
Collaborator Author

I will attempt a prototype implementation to see whether this is feasible, and if it is, I will create a cpython issue and PR.

@gvanrossum gvanrossum self-assigned this Mar 18, 2024
@JelleZijlstra
Copy link
Contributor

Linking to python/cpython#109998 where I found that we're inconsistent about whether writing to certain function attributes bumps the function version. I didn't do anything about it because I don't understand this code well and it didn't seem likely to matter in practice, but if you're redoing the way function versions are handled, it might be worth also fixing this inconsistency.

@gvanrossum
Copy link
Collaborator Author

gvanrossum commented Mar 19, 2024

It looks feasible, see python/cpython#117028. I have created python/cpython#117045 to debate a better internal API.

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

No branches or pull requests

2 participants