Skip to content

Leak fixes redux#9359

Merged
headius merged 7 commits intojruby:jruby-10.0from
headius:leak_fixes
Apr 6, 2026
Merged

Leak fixes redux#9359
headius merged 7 commits intojruby:jruby-10.0from
headius:leak_fixes

Conversation

@headius
Copy link
Copy Markdown
Member

@headius headius commented Apr 3, 2026

This PR will reconsider and apply appropriate fixes from #9315.

The fixes and analysis in that PR were performed by Copilot, and after several of them turned out to be unnecessary or incorrect, we lost faith that any of the fixes were correct or based on sound analysis. This PR will attempt to re-visit that analysis and apply only necessary, correct fixes.

@headius headius added this to the JRuby 10.0.5.0 milestone Apr 3, 2026
The runtime is cleared to remove another reference and assist GC.

The termination flag is added to ensure a terminated LocalContext
is not used for any further changes.
headius added 5 commits April 3, 2026 14:10
The function here previously was an instance method, rooting a
reference to the ClassValue via JavaSupport. This caused the
proxy class contained in the ClassValue to be permanently hard-
referenced, preventing the JRuby runtime from being collected.

The new function is static and accepts the runtime and lock
previously accessed via the JavaSupport reference. Once the
JavaSupport has been removed from the runtime on tearDown, the
chain of references to this class value is broken and all
objects downstream of JavaSupport are unrooted.
LoadService.tearDown calls RubyArray.clear on the loaded features,
which uses the current thread context for error handling. Errors
here should be exceedingly rare, but if they are raised the will
need a proper ThreadContext to construct and propagate properly.
Locking against the StableClassValue causes the StableValue to
have a hard reference back to the ClassValue that contains it,
preventing the ClassValue from ever vacating. This leaks memory no
matter what the StableValue contains.
We can actively clear ThreadContext references and remove the
ThreadLocal association for the tearDown thread.
Continue isolating the ClassValue calculators from JavaSupport.

* Use weak references to avoid rooting state needed by the
  calculators.
* Use static factory methods to ensure no attachment to the
  surrounding JavaSupport object.
* Add a clear method to our ClassValue for best-effort clearing.
* StableClassValue tracks StableValue instances to actively clear
  them at tearDown.
* Clear as many references as possible.
@jimtng
Copy link
Copy Markdown
Contributor

jimtng commented Apr 5, 2026

Thanks for the fix, @headius! My openhab test setup is no longer leaking with this.

This test runs some very basic verifications of the GCability of
the Ruby runtime associated with a ScriptingContainer once it has
been terminated.

See jruby#520
@headius headius merged commit 52ec5c6 into jruby:jruby-10.0 Apr 6, 2026
98 of 100 checks passed
@headius headius deleted the leak_fixes branch April 6, 2026 01:43
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

2 participants