Message9804

Kevin, I have given some more thought to this problem. We have two sets of objects - Threads and ThreadState - which we are mapping with ThreadStateMapping.cachedThreadState. Threads may either run a single task, or be used in a thread pool to avoid the overhead of constructring new threads for a given task, with very different lifetimes. ThreadState objects are lightweight and simply track a mapping to PySystemState, along with some other dynamically scoped data, such as call_depth.

Because there are independent lifetimes on both sides, the mapping should be weak keys AND weak values (so I was wrong in msg9795). Otherwise a ThreadState could stop a Thread from being GC'ed, and vice versa. In particular, we don't want a long running Thread object in a thread poool to not be able to unload the Jython runtime, because it's strongly referring to a ThreadState, which in turn strongly refers to a PySystemState.

Interestingly, there's a small but significant performance improvement in benchmarks (my recollection is 10% or so on pystone) because even though the ThreadState can generally be recreated as necessary, just to avoid additional lookups.

However, this weak key/weak value mapping will raise an issue with code patterns like so, if there's no other reference to the PySystemState than a newly allocated ThreadState:

Py.setSystemState(new PySystemState());

In the Jython codebase, there's one example of the above fragment of code in restarting an interpreter. In this case it looks like the initialization will be done twice. However, this doesn't appear to do anything wrong, just slightly less efficient. In all other cases in the Jython codebase, such as by using a PythonInterpreter, a PySystemState always is being referred to with a strong reference, so there's no loss of this state.

We decided in 2.7 that we would make backwards breaking changes that we could not do in 2.5, as discussed in #1327, if it solves long standing memory leaks and other problems.