[New-bugs-announce] [issue45550] Increase the information content and robustness of tp_version_tag.

Mark Shannon report at bugs.python.org
Thu Oct 21 06:16:53 EDT 2021


New submission from Mark Shannon <mark at hotpy.org>:

Currently, we use the `tp_version_tag` as a proxy for the state of a class when specializing.
When we have issued 2**32 tags, we stop issuing tags. This prevents specializing of classes that need a new tag.

We can make a few enhancements:

1. Reserve the low 2**M (M probably 4 or 5) values for special classes. This would allow us to perform some type checks efficiently in a multiple-interpreter environment.
`PyLongCheck_Exact(ob)` is currently `Py_TYPE(ob) == &PyLong_Type` but could become `Py_TYPE(ob)->tp_version_tag == PY_INT_VERSION_TAG`. No need to access the interpreter state.

2. Reserve the low 2**N (N somewhere in range 10 to 16) for builtin classes. Maybe split this into immutable and mutable. 
We often need to load the version tag, this would save another load from tp_flags to check for builtin-ness and (im)mutability.

3. Add a modified count to the type struct. When this reaches a threshold, no longer issue tags for this class.
This would prevent pathological classes consuming millions of tags. Only needs 16 bits.

The reason we want power of two boundaries is so that we can test multiple types at once.
E.g. T1 and T2 are both "special" if `(T1->tp_version_tag | T2->tp_version_tag) < 2**M`

----------
assignee: Mark.Shannon
components: Interpreter Core
messages: 404580
nosy: Mark.Shannon
priority: normal
severity: normal
status: open
title: Increase the information content and robustness of tp_version_tag.
type: performance
versions: Python 3.11

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue45550>
_______________________________________


More information about the New-bugs-announce mailing list