Skip to content

Commit 7e1f38f

Browse files
authored
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`.
1 parent 76d0868 commit 7e1f38f

File tree

4 files changed

+7
-9
lines changed

4 files changed

+7
-9
lines changed

Include/internal/pycore_interp.h

-1
Original file line numberDiff line numberDiff line change
@@ -245,7 +245,6 @@ struct _is {
245245

246246
uint16_t optimizer_side_threshold;
247247

248-
uint32_t next_func_version;
249248
_rare_events rare_events;
250249
PyDict_WatchCallback builtins_dict_watcher;
251250

Objects/codeobject.c

+3-3
Original file line numberDiff line numberDiff line change
@@ -415,9 +415,9 @@ init_code(PyCodeObject *co, struct _PyCodeConstructor *con)
415415
co->co_ncellvars = ncellvars;
416416
co->co_nfreevars = nfreevars;
417417
PyInterpreterState *interp = _PyInterpreterState_GET();
418-
co->co_version = interp->next_func_version;
419-
if (interp->next_func_version != 0) {
420-
interp->next_func_version++;
418+
co->co_version = interp->func_state.next_version;
419+
if (interp->func_state.next_version != 0) {
420+
interp->func_state.next_version++;
421421
}
422422
co->_co_monitoring = NULL;
423423
co->_co_instrumentation_version = 0;

Objects/funcobject.c

+4-4
Original file line numberDiff line numberDiff line change
@@ -236,8 +236,9 @@ How does a function's `func_version` field get initialized?
236236
- A new version is allocated by `_PyFunction_GetVersionForCurrentState`
237237
when the specializer needs a version and the version is 0.
238238
239-
The latter allocates versions using a counter in the interpreter state;
240-
when the counter wraps around to 0, no more versions are allocated.
239+
The latter allocates versions using a counter in the interpreter state,
240+
`interp->func_state.next_version`.
241+
When the counter wraps around to 0, no more versions are allocated.
241242
There is one other special case: functions with a non-standard
242243
`vectorcall` field are not given a version.
243244
@@ -247,8 +248,7 @@ Code object versions
247248
--------------------
248249
249250
So where to code objects get their `co_version`?
250-
There is a per-interpreter counter, `next_func_version`.
251-
This is initialized to 1 when the interpreter is created.
251+
They share the same counter, `interp->func_state.next_version`.
252252
253253
Code objects get a new `co_version` allocated from this counter upon
254254
creation. Since code objects are nominally immutable, `co_version` can

Python/pystate.c

-1
Original file line numberDiff line numberDiff line change
@@ -630,7 +630,6 @@ init_interpreter(PyInterpreterState *interp,
630630
interp->sys_profile_initialized = false;
631631
interp->sys_trace_initialized = false;
632632
(void)_Py_SetOptimizer(interp, NULL);
633-
interp->next_func_version = 1;
634633
interp->executor_list_head = NULL;
635634
if (interp != &runtime->_main_interpreter) {
636635
/* Fix the self-referential, statically initialized fields. */

0 commit comments

Comments
 (0)