Message5837

I have been doing some more investigation here, using visualvm to find all the references to the classloader being leaked.

Philip, you are right about the thread-local PySystemState - I put try {} around my use of the python interpreter with Py.setSystemState(null) in the finally block, which seemed to help. 

As an aside, jython's use of thread-local storage for system state is really aggravating - I have run into bugs in the past where a python script calls into java which calls back into jython, and my system state has been clobbered - basically I now use the following pattern every time I run a script through a PythonInterpreter: save off the current state, run the script, and reset the state to the old value in a finally{} block. It would be *so* much nicer if jython could do this for me, or just not use TLS at all!

I found another place where classloaders were being leaked as well: PyFile's Closer class. Apparently a Closer object is registered with the JVM each time a PyFile is created and used. If the jython jar is in a servlet then this contains a reference to the servlet's classloader and thus the servlet's classes will never be cleaned up after the servlet is reloaded. Doesn't the JVM handle closing open file handles on exit (or doesn't the operating system handle that?) Why does this code exist? It seems to me that we could safely remove the Closers from PyFile and fix this memory leak. What do you think?

I am continuing to look at this, and will let you know if I find anything else....