Jython, GILs and object locking.

[Jon Franz_antispam]

> I meant dynamic objects. In the Python code
> a = b
> the count for b gets incremented and the count of the object a points to
> gets decremented.
>
> Reference counters are being changed almost everywhere in Python, when
> tuples are created, when parameters are passed to a method etc. All this
> will get slower because access to the counters has to be synchronized.
>
> One could try to remove reference counting along with the GIL, but that
has
> other repercussions, some for extension writers, some for the language
> CPython (Jython has already these problems).

What if the reference counter system became smart enough so that there were
n+1 'pools' of objects?  n thread-local pools, and one global pool (for
objects
that are in the global scope).  This could be painful to implement, and
would
have far-reaching repercussions, but it would remove the locking on
reference
counting for local variables that only have meaning within a specific thread
context.

Of course, excessive use of global scope variables would lead to a lot of
short
term locks being grabbed and released by Py_INCREF and Py_DECREF,
which could be more damaging than the GIL if not avoided.  Making the
system 'smart' enough to not lock and release when only one thread is
running would be a good thing.

I'm just thinking out loud here... thoughts?

~Jon Franz