https://github.com/python/cpython/commit/7e1f38f2de8f93de362433203faa5605a0c47f0e
commit: 7e1f38f2de8f93de362433203faa5605a0c47f0e
branch: main
author: Guido van Rossum <gu...@python.org>
committer: gvanrossum <gvanros...@gmail.com>
date: 2024-03-18T11:11:10-07:00
summary:
gh-116916: Remove separate next_func_version counter (#116918)
Somehow we ended up with two separate counter variables tracking "the next
function version".
Most likely this was a historical accident where an old branch was updated
incorrectly.
This PR merges the two counters into a single one:
`interp->func_state.next_version`.
files:
M Include/internal/pycore_interp.h
M Objects/codeobject.c
M Objects/funcobject.c
M Python/pystate.c
diff --git a/Include/internal/pycore_interp.h b/Include/internal/pycore_interp.h
index d79fd3b6039ef5..942f47340b3966 100644
--- a/Include/internal/pycore_interp.h
+++ b/Include/internal/pycore_interp.h
@@ -245,7 +245,6 @@ struct _is {
uint16_t optimizer_side_threshold;
- uint32_t next_func_version;
_rare_events rare_events;
PyDict_WatchCallback builtins_dict_watcher;
diff --git a/Objects/codeobject.c b/Objects/codeobject.c
index 30336fa86111a7..3df733eb4ee578 100644
--- a/Objects/codeobject.c
+++ b/Objects/codeobject.c
@@ -415,9 +415,9 @@ init_code(PyCodeObject *co, struct _PyCodeConstructor *con)
co->co_ncellvars = ncellvars;
co->co_nfreevars = nfreevars;
PyInterpreterState *interp = _PyInterpreterState_GET();
- co->co_version = interp->next_func_version;
- if (interp->next_func_version != 0) {
- interp->next_func_version++;
+ co->co_version = interp->func_state.next_version;
+ if (interp->func_state.next_version != 0) {
+ interp->func_state.next_version++;
}
co->_co_monitoring = NULL;
co->_co_instrumentation_version = 0;
diff --git a/Objects/funcobject.c b/Objects/funcobject.c
index 08b2823d8cf024..a506166916de48 100644
--- a/Objects/funcobject.c
+++ b/Objects/funcobject.c
@@ -236,8 +236,9 @@ How does a function's `func_version` field get initialized?
- A new version is allocated by `_PyFunction_GetVersionForCurrentState`
when the specializer needs a version and the version is 0.
-The latter allocates versions using a counter in the interpreter state;
-when the counter wraps around to 0, no more versions are allocated.
+The latter allocates versions using a counter in the interpreter state,
+`interp->func_state.next_version`.
+When the counter wraps around to 0, no more versions are allocated.
There is one other special case: functions with a non-standard
`vectorcall` field are not given a version.
@@ -247,8 +248,7 @@ Code object versions
--------------------
So where to code objects get their `co_version`?
-There is a per-interpreter counter, `next_func_version`.
-This is initialized to 1 when the interpreter is created.
+They share the same counter, `interp->func_state.next_version`.
Code objects get a new `co_version` allocated from this counter upon
creation. Since code objects are nominally immutable, `co_version` can
diff --git a/Python/pystate.c b/Python/pystate.c
index 9f142223aff340..eedcb920cd1cf2 100644
--- a/Python/pystate.c
+++ b/Python/pystate.c
@@ -630,7 +630,6 @@ init_interpreter(PyInterpreterState *interp,
interp->sys_profile_initialized = false;
interp->sys_trace_initialized = false;
(void)_Py_SetOptimizer(interp, NULL);
- interp->next_func_version = 1;
interp->executor_list_head = NULL;
if (interp != &runtime->_main_interpreter) {
/* Fix the self-referential, statically initialized fields. */
_______________________________________________
Python-checkins mailing list -- python-checkins@python.org
To unsubscribe send an email to python-checkins-le...@python.org
https://mail.python.org/mailman3/lists/python-checkins.python.org/
Member address: arch...@mail-archive.com
