On 4/12/07, Greg Ewing <greg.ewing@canterbury.ac.nz> wrote:
I've been thinking about some ideas for reducing the amount of refcount adjustment that needs to be done, with a view to making GIL removal easier.
1) Permanent objects
I have some vague memory (but couldn't find the references) that someone tried and it was too expensive. INCREF and DECREF on something in the header of an object you need anyhow were just too small to beat once you added any logic. (That said, the the experiment was pretty old, and the results may have changed.)
2) Objects owned by a thread
[Create a owner-refcount separate from the global count] Some distributed systems already take advantage of the fact that the actual count is irrelevant. They use weights, so that other stores don't need to be updated until the (local) weight hits zero. While it would be reasonable for a thread to only INCREF once, and then keep its internal refcount elsewhere ... it is really hard to beat "(add1 to/subtract 1 from) an int already at a known location in cache." Also note that Mark Miller and Ping Yee http://www.eros-os.org/pipermail/e-lang/1999-May/002590.html suggested a way to mark objects as "expensive" (==> release as soon as possible). Combining this, today's python looks only at an object's size when determining which memory pool to use. There might be some value in also categorizing types based on their instances typical memory usage. Examples: (1) Default pool, like today. (2) Permanent Pool: Expected to be small and permanent. Maybe skip the refcount entirely? Or at least ignore it going to zero, so you don't need to lock for updates? (3) Thread-local. Has an "external refcount" field that would normally be zero. (4) Expensive: Going to a rooted GC won't release it fast enough. -jJ