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.