CPython optimization: storing reference counters outside of objects
Hi, 2011/5/23 Sturla Molden <sturla@molden.no>:
Does this mean that the PyObject* address would change? How would you update all the places that store moved references? -- Amaury Forgeot d'Arc
Den 23.05.2011 20:22, skrev Amaury Forgeot d'Arc:
Does this mean that the PyObject* address would change? How would you update all the places that store moved references?
That is a good point. How does the generational GC of .NET and Java deal with object relocation? Perhaps we don't need to allocate new memory and memcpy. A heap is called a "heap" because it is a priority queue of contiguous memory buffers -- free size being the criterion for partial sorting. So we pop the buffer (or parts of it?) containing the PyObject off one heap and paste it to another, the PyObject* will not change. This might not be efficient for cache lines however. Also, there is the question of attributes. Preferably a Python object and its attributes should reside on the same cache line. Sturla
Den 23.05.2011 20:22, skrev Amaury Forgeot d'Arc:
Does this mean that the PyObject* address would change? How would you update all the places that store moved references?
That is a good point. How does the generational GC of .NET and Java deal with object relocation? Perhaps we don't need to allocate new memory and memcpy. A heap is called a "heap" because it is a priority queue of contiguous memory buffers -- free size being the criterion for partial sorting. So we pop the buffer (or parts of it?) containing the PyObject off one heap and paste it to another, the PyObject* will not change. This might not be efficient for cache lines however. Also, there is the question of attributes. Preferably a Python object and its attributes should reside on the same cache line. Sturla
participants (2)
-
Amaury Forgeot d'Arc -
Sturla Molden