-
-
Notifications
You must be signed in to change notification settings - Fork 924
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
scriptingcontainer native memory leak? #1791
Comments
Heap dump of a run of this code, if anyone is interested: https://github.com/cprice404/jruby-puppet-compile-memleak/tree/heap-dump/heapdumps |
Hello, I've been working w/ @cprice404 on this issue, and I was able to boil this down to a very simple program that seems to demonstrate a fairly severe native memory leak: https://github.com/KevinCorcoran/jruby-memory-leak I'm very interested to hear any thoughts on this. Thanks! |
ScriptingContainer has |
@yokolet - Thanks for the response. Unfortunately, your proposed solution doesn't work for our use-case - we are using persistent ScriptingContainers that are initialized on application startup. Our main reason for doing this is that we need to load a relatively large ruby codebase into each container, and this is a time-consuming process. So we never |
I've opened #1888 to cover the issue of the simple reproduction case and native memory leak. |
Should this issue be closed out now since #1888 has been resolved, or is there still something to be fixed? |
Yeah, I'm not aware of any outstanding work to be done here. Closing. Thanks for the bump @rtyler . |
We're experimenting with using JRuby to compile Puppet catalogs. We'd like to use a ScriptingContainer to give us some control over the JRuby instance.
Everything is working very well, but there are some memory issues that I'm having a hard time figuring out. The two main problems are:
I've put together a repro case here:
https://github.com/cprice404/jruby-puppet-compile-memleak
Connecting to the process after the ScriptingContainer goes out of scope, I can see that the heap still contains a large number of references to instances of this type:
So I'm suspicious that that may have something to do with it (mostly just based on the name of that class :) ).
It's possible/likely that the actual ruby code we're running inside of the JRuby ScriptingContainer has memory leaks that we need to fix, but I'd have guessed / hoped that GC'ing the ScriptingContainer would be a feasible workaround for freeing up that memory.
I don't have a tremendous amount of experience debugging JVM -> native memory allocation, so if anyone has any pointers on how to debug this, they'd be greatly appreciated! I'm also happy to take this to a mailing list, IRC, etc. if there is a more appropriate forum.
The text was updated successfully, but these errors were encountered: