Fix memory leak and upgrade to JRuby 9.4.15.0#81
Merged
Conversation
Signed-off-by: Charlie Sharpsteen <charlie@overlookinfratech.com>
Over the history of JRuby use in the server, there have been several incidents where a JRuby instance survives the shutdown of the JRuby pool service. This is one of the most severe memory leaks possible for the Server as it results in at least several hundred megabytes leaked for the Runtime, and then an indeterminate amount of additional leaked RAM for module content and user data. This commit adds an integration test that spins up a JRuby pool, exercises it with some Ruby code, and then shuts it down. After shutdown, `java.lang.System.gc()` is called and the test asserts that the JRuby instances are destroyed by the garbage collector. The lifecycle of this test case is unusual in that it runs everything on a separate thread pool that is also shut down at the end of the test. This is done because any Java Thread that calls into a JRuby instance to execute Ruby code gains a soft reference to that JRuby. Soft references are not released by regular `System.gc()`, the JVM has to be put under actual memory pressure before it panics and destroys them --- and forcing an `OutOfMemory` error in the test case and then rescuing it is a bit too spicy. This test will not detect all usage patterns that lead to a JRuby leaking. Currently, it targets an issue introduced in the 9.4.13.0 release of JRuby that results in proxy objects, created when Ruby code calls into Java, holding onto strong references to the JRuby instance. If additional usage patterns lead to occurring, they can be added as new cases on this test. Co-Authored-By: Claude Fable 5 <noreply@anthropic.com> Signed-off-by: Charlie Sharpsteen <charlie@overlookinfratech.com>
The JRuby 9.4.13.0 release re-factored storage of proxy objects that get created when Ruby code interacts with Java classes. Prior versions of JRuby stored these proxies in a hashmap owned by the JRuby interpreter that has the unfortunate behavior of growing without bound if the number of unique Java interactions is not limited. JRuby 9.4.13.0 introduced a new `STABLE` accounting method the attempts to address this by using weak references to the proxies attached to the Java classes themselves. Unfortunately, there was a strong reference mixed in that is not cleared when a JRuby instance shuts down and that makes shut-down JRubies unavailable for garbage collection. This causes the OpenVox Server tests to throw `OutOfMemoryError` when JRuby is upgraded past 9.4.12.1 as the tests spin up and then shut down several JRuby pools. This commit fixes the glitch by pinning the `ji.class.values` setting to the old `HARD_MAP` default. The leak is fixed by upstream PR jruby/jruby#9359 which was released with JRuby 10.0.5.0. The new default of `STABLE` should be usable starting with that version. Fixes OpenVoxProject#76 Signed-off-by: Charlie Sharpsteen <charlie@overlookinfratech.com>
This upgrade is possible now that the memory leak described in OpenVoxProject#76 is fixed. Signed-off-by: Charlie Sharpsteen <charlie@overlookinfratech.com>
The logic for initializing JRuby instances sets `jruby.invokedynamic.yield` to `false` instead of the default value of `true`. This was done to resolve a stack overflow that is described in jruby/jruby#6260. That issue was fixed upstream with the release of JRuby 9.2.15.0. Making a large change to optimizer behavior is a bit much for a stable release, so this commit adds a `FIXME` note to drop the override when taking up JRuby 10. Signed-off-by: Charlie Sharpsteen <charlie@overlookinfratech.com>
corporate-gadfly
approved these changes
Jul 6, 2026
bastelfreak
approved these changes
Jul 6, 2026
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
3 participants
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
Short description
This changeset adds a test for the memory leak reported in #76, then a fix for the leak, and finally an upgrade to the 9.4.15.0 release of JRuby. JRuby 9.4.x is now end-of-life, these changes get us caught up on fixes and lay the groundwork for moving to JRuby 10.
Checklist
I have:
Signed-off-byannotation to each of my commitsGenerated-byorAssisted-byannotations to each of my commits created with the help of an AI agent