We are doing an audit of JRuby and related projects looking for static references to JRuby state, since those references can anchor the JRuby instance, the classloader that loaded JRuby, and more.

I have fixed a number of cases for 9.1 in f248488. I fixed a few additional cases on master (9.2) in 95a41f9.

Here are my notes on other cases that did not have an easy fix...but they may not be problems.

• Several static ThreadLocal in FFI, may anchor classloader that loaded those classes.
• DataConverters.enumConverters is a static weak map of IRubyObject to converter, may work ok but uses our WeakIdentityHashMap, may anchor classloader. Keys may also interact weirdly across runtimes.
• IR Profiler uses static collections for much of its data gathering.
• Ruby < Java subclass creation uses static values during construction and possible in the generated class, with non-weak references to the runtime. Most during construction appear to be cleaned up (set back to original probably-null value).
• Ruby implementing Java interfaces uses static fields for call sites. The generated class should be rootless, but this has been reported as a "leak" because the class holds on to too much data.
• JarResource stores cache in a static field. Data should be weak, but this may need to be audited for leak potential.
• (deprecate relevant code paths) BlockingIO caches selectors in a static CHM, mapping SelectorProvider to IOSelector. The latter will anchor SelectorProvider instances + classloader, and latter will anchor JRuby's classloader, but both are local (static global) to JRuby's classloader.
• RubyEncoding has a ThreadLocal<SoftReference> which could anchor JRuby's classloader (for UTF8Coder) longer than would be ideal.
• Embedding's SingletonLocalContextProvider holds a static reference to a runtime via localContext field. This may be by design.