[Python-ideas] Ideas towards GIL removal

[Jim Jewett]

On 4/12/07, Greg Ewing <greg.ewing at 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