Bug report
Bug description:
_PyType_LookupRefAndVersion will populate the incorrect cache entry if it is called with a type that does not have a version tag (tp_version_tag is 0). I think this only impacts performance, not correctness. The next call to _PyType_LookupRefAndVersion for the same (type, name) pair will miss the cache, but will populate the correct entry, so any subsequent calls will hit the cache. Additionally, this may create some amount of unnecessary thrash on the cache.
The root of the issue is that the version tag is an input to the hash that is used to determine the cache entry and we do not recompute the hash, and the associated cache entry, after assigning a version.
_PyType_LookupRefAndVersion first computes the cache entry:
|
unsigned int h = MCACHE_HASH_METHOD(type, name); |
|
struct type_cache *cache = get_type_cache(); |
|
struct type_cache_entry *entry = &cache->hashtable[h]; |
If the cache entry doesn't match, and a type version was assigned successfully, it populates the same entry:
|
#if Py_GIL_DISABLED |
|
update_cache_gil_disabled(entry, name, assigned_version, res); |
|
#else |
|
PyObject *old_value = update_cache(entry, name, assigned_version, res); |
|
Py_DECREF(old_value); |
|
#endif |
The next call for the same (type, name) pair, will find a different entry, because the type version is used to compute the hash that indexes into the cache:
|
#define MCACHE_HASH_METHOD(type, name) \ |
|
MCACHE_HASH(FT_ATOMIC_LOAD_UINT32_RELAXED((type)->tp_version_tag), \ |
|
((Py_ssize_t)(name)) >> 3) |
It looks like the change to use the same entry was introduced in gh-113930. cc @DinoV
CPython versions tested on:
3.13, 3.14
Operating systems tested on:
Linux
Bug report
Bug description:
_PyType_LookupRefAndVersionwill populate the incorrect cache entry if it is called with a type that does not have a version tag (tp_version_tagis 0). I think this only impacts performance, not correctness. The next call to_PyType_LookupRefAndVersionfor the same (type, name) pair will miss the cache, but will populate the correct entry, so any subsequent calls will hit the cache. Additionally, this may create some amount of unnecessary thrash on the cache.The root of the issue is that the version tag is an input to the hash that is used to determine the cache entry and we do not recompute the hash, and the associated cache entry, after assigning a version.
_PyType_LookupRefAndVersionfirst computes the cache entry:cpython/Objects/typeobject.c
Lines 5542 to 5544 in 39e69a7
If the cache entry doesn't match, and a type version was assigned successfully, it populates the same entry:
cpython/Objects/typeobject.c
Lines 5629 to 5634 in 39e69a7
The next call for the same (type, name) pair, will find a different entry, because the type version is used to compute the hash that indexes into the cache:
cpython/Objects/typeobject.c
Lines 46 to 48 in 39e69a7
It looks like the change to use the same entry was introduced in gh-113930. cc @DinoV
CPython versions tested on:
3.13, 3.14
Operating systems tested on:
Linux