This is a pull request to fix a leak I have observed when using Jython embedded in an application capable of reloading its classloader. When there is a SecurityManager, the ShutdownCloser thread from PySystemStateCloser remains forever in a field named subclassAudits in java.lang.Thread, preventing proper garbage-collection.
The solution is simple: ShutdownCloser can implement Runnable instead of extending Thread. Note that there are other classes extending Thread in Jython, so it may be interesting to apply the same change to them (I have not investigated further myself).
Here is an image showing the path to the GC root from the classloader, showing that a reference to the ShutdownCloser thread prevents an unused classloader from being garbage-collected. This path was obtained Yourkit, with Jython embedded in Icy (an open-source image-analysis program). Two classloaders are shown : the top one is the live one, the bottom one is not used anymore and should be garbage-collected. The failure to garbage-collect it ultimately causes an out-of-memory in the PermGenSpace of Icy. As shown, a reference to the ShutdownCloser thread is being kept in a field named subclassAudits. This is not directly Jython's fault but rather a bug in Java. Wayway, defining ShutdownCloser as a Runnable instead of a Thread solves this problem.
Thanks very much for submitting your PR. This is a very straightforward way to fix the problem, given the context explained in the cited Guava issue. Also it seems to be cleaner to simply implement a Runnable than subclass a Thread.