CPython optimization: storing reference counters outside of objects
Hi, 2011/5/23 Sturla Molden <sturla@molden.no>:
Instead, we could use multiple heaps:
Each Python thread could manage it's own heap for malloc and free (cf. HeapAlloc and HeapFree in Windows). Objects local to one thread only reside in the locally managed heap.
When an object becomes shared by seveeral Python threads, it is moved from a local heap to the global heap of the process. Some objects, such as modules, would be stored directly onto the global heap.
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
participants (2)
-
Amaury Forgeot d'Arc -
Sturla Molden