Fix runtime and classloader retention after ScriptingContainer terminate#9315
Fix runtime and classloader retention after ScriptingContainer terminate#9315jimtng wants to merge 3 commits intojruby:jruby-10.0from
Conversation
Clear lingering ThreadContext soft references during teardown, drop the embed LocalContext runtime reference, and avoid re-adopting the current thread while Ruby is shutting down. Also switch Java integration class caches to weak values and avoid recreating JavaSupport during teardown so terminated runtimes and their JRubyClassLoaders can be collected promptly. Add regression coverage for same-thread and worker-thread container termination. Fixes jrubyGH-9092 Signed-off-by: Jimmy Tanagra <jcode@tanagra.id.au>
|
There's clearly some issues here but I'd like to figure out how to land a fix. It seems that the weak references to the class values is too weak, and I'm not sure we should be using weak references at this point anyway. If they're weak and a JavaClass goes unreferenced for a couple of GC cycles, it will end up getting collected and a future access will cause it to be recreated. That's the source of all the reinitialized constant warnings and the reason the test/jruby tests fail here. Even a SoftReference is probably too weak, since it just delays the time until the JavaClass gets collected. Is that part of the patch necessary for this to work? Is clearing the reference to the JavaSupport class not enough? |
Signed-off-by: Jimmy Tanagra <jcode@tanagra.id.au>
Yes it's necessary. Reverting only the JavaSupport/ClassValue part causes all three GH-9092 regression tests in ScriptingContainerClassLeakTest to fail, and restoring it makes that test class pass again. So that part is necessary for the leak fix, not for normal runtime cache behavior. If you have a cleaner lifecycle-based alternative, I’m happy to switch to that. |
|
My question was really if we need both changes. Clearing the reference to the JavaSupport instance seems like it would be sufficient, and making the Java class references weak leads to other problems quickly. I can give it a try myself when I'm in the office. |
Signed-off-by: Jimmy Tanagra <jcode@tanagra.id.au>
2 participants
Clear lingering ThreadContext soft references during teardown, drop the embed LocalContext runtime reference, and avoid re-adopting the current thread while Ruby is shutting down.
Also switch Java integration class caches to weak values and avoid recreating JavaSupport during teardown so terminated runtimes and their JRubyClassLoaders can be collected promptly.
Add regression coverage for same-thread and worker-thread container termination.
Fixes #9092, Fixes #9070, Fixes openhab/openhab-jruby#520
Note: I asked an AI tool to help identify this issue. I verified the result on a patched JRuby 10.0.4.0 running inside openHAB, where the memory leak had previously been observed. After applying the fix, the GC consistently returned the heap to its original size, even after repeated script‑engine creation and teardown cycles.