Skip to content
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

Closed
cprice404 opened this Issue Jul 5, 2014 · 7 comments

Comments

Projects
None yet
5 participants
@cprice404
Copy link
Contributor

cprice404 commented Jul 5, 2014

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:

  • The ScriptingContainer seems to be capable of allocating a lot of memory that is outside of the Java heap (e.g. we see resident memory usage at the OS level go well beyond the JVM max heap size), and
  • When we are finished with the ScriptingContainer and attempt to garbage collect / finalize it, the non-JVM memory is not freed

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:

org.jruby.internal.runtime.methods.DynamicMethod$NativeCall[]

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.

@cprice404

This comment has been minimized.

Copy link
Contributor Author

cprice404 commented Jul 8, 2014

Heap dump of a run of this code, if anyone is interested:

https://github.com/cprice404/jruby-puppet-compile-memleak/tree/heap-dump/heapdumps

@KevinCorcoran

This comment has been minimized.

Copy link

KevinCorcoran commented Aug 5, 2014

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!

@yokolet

This comment has been minimized.

Copy link
Member

yokolet commented Aug 5, 2014

ScriptingContainer has terminate and finalize methods, which may release memory. Have you ever tried those methods?

@KevinCorcoran

This comment has been minimized.

Copy link

KevinCorcoran commented Aug 5, 2014

@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 terminate or finalize a ScriptingContainer until the application shuts down.

@KevinCorcoran

This comment has been minimized.

Copy link

KevinCorcoran commented Aug 6, 2014

I've opened #1888 to cover the issue of the simple reproduction case and native memory leak.

@rtyler

This comment has been minimized.

Copy link

rtyler commented Dec 3, 2014

Should this issue be closed out now since #1888 has been resolved, or is there still something to be fixed?

@cprice404

This comment has been minimized.

Copy link
Contributor Author

cprice404 commented Dec 3, 2014

Yeah, I'm not aware of any outstanding work to be done here. Closing. Thanks for the bump @rtyler .

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
You can’t perform that action at this time.