Reevaluate for 9.3.

Reviewing this in advance of 9.3 release.

Several static ThreadLocal in FFI, may anchor classloader that loaded those classes.

These all appear to be soft references. They will linger but should not leak in an unbounded way.

Several static ThreadLocal in FFI, may anchor classloader that loaded those classes.

This does not seem to be a problem. The map is weak-keyed, so should clear out after a runtime goes away, and uses identity to look up the value, which will isolate calls across runtimes.

Ruby < Java subclass creation uses static values during construction and possible in the generated class

Java subclasses are not intended to be usable across runtimes, and should be loading the generated class into our child JRubyClassLoader. @byteit101 may have comments here relating to #6422.

Ruby implementing Java interfaces uses static fields for call sites

I am not sure which issue is the "leak" mentioned here. Java interface implementations are, like Java subclasses, intended to be used only in the originating JRuby instance, and should be collected with that instance (and its JRubyClassLoader) is expunged.

JarResource stores cache in a static field

This is still the case, and I am still unsure if it is safe.

BlockingIO caches selectors in a static CHM, mapping SelectorProvider to IOSelector

SelectorProvider is loaded in the same classloader as this static CHM and the IOSelector instances should have no links to JRuby's runtime. This code is also deprecated and/or unused now (deprecate remaining references to this logic).

RubyEncoding has a ThreadLocal which could anchor JRuby's classloader

This is no more or less worrisome than other soft referenced threadlocals to JRuby-specific classes. We will deal with leak reports in the future (have had none about this or the other soft threadlocals above).

Embedding's SingletonLocalContextProvider holds a static reference to a runtime via localContext field. This may be by design.

This is by design. We may want to consider phasing this model out.

JarResource stores cache in a static field

This is still the case, and I am still unsure if it is safe.

The implementation is safe and the actual caches indices are stored weakly, so I think this is a non-issue.

IR Profiler uses static collections for much of its data gathering.

Still an issue but not a complete or supported feature and not enabled by default. Additional work can clean up static fields.

Calling this one resolved. Remaining static references are either non-issues or not part of supported/active code.