Debugging permgen issues

I’m having a hard time reading through the output of tools like jmap
and being able to tell what looks wrong. This is a jruby 1.6.5/tomcat
7 rails app where the permgen just keeps inching up and up. So far
I’ve never seen it go down.

The total output for jmap -permstats is over 2000 lines. This is a
sampling. I’m not really sure what I should be looking for here. If
anyone has suggestions on what my next step should be that would help
a lot. I visualvm running also if that can be of use. I’m using that
to watch memory use of heap and permgen.

Heap usage is not growing at a constant rate, it’s actually
fluctuating over time, while permgen is just a constant upward trend
it never goes down.


class_loader classes bytes parent_loader alive? type
1924 10492248 null live

The large majority of the entries look like this. The one shot

loader referencing a small number of classes
0x00000005e8db7720 7 300208 0x00000005e02eb350 dead
org/jruby/util/[email protected]
0x00000005eab7a748 6 179928 0x00000005e02eb350 dead
org/jruby/util/[email protected]
0x00000005e161f968 6 178192 0x00000005e02eb350 dead
org/jruby/util/[email protected]
0x00000005eab85750 7 183624 0x00000005e02eb350 dead
org/jruby/util/[email protected]

Second most common are the jruby class loaders, most of them look like

0x00000005e93091a0 4 16056 0x00000005eab76720 dead
org/jruby/util/[email protected]
0x00000005e2a296a8 7 100112 0x00000005e2a296f8 dead
org/jruby/util/[email protected]

Couple of these have a lot of references

0x00000005e02eb350 4927 20736792 0x00000005e0076060
dead org/apache/catalina/loader/[email protected]
0x00000005e0076060 959 7476160 0x00000005e001c000 dead
org/apache/catalina/loader/[email protected]

This is the only jruby class loader that had a lot of references

0x00000005e0450b78 1517 7110264 0x00000005e02eb350 dead
org/jruby/util/[email protected]

total = 2574 27566 707593448 N/A alive=1,
dead=2573 N/A

At 12:56 PM -0800 12/28/11, snacktime wrote:

to watch memory use of heap and permgen.

Heap usage is not growing at a constant rate, it’s actually
fluctuating over time, while permgen is just a constant upward trend
it never goes down.

Have you seen this post:
perhaps it’s helpful.

On Dec 28, 2011, at 5:12 PM, Stephen B. wrote:

Have you seen this post: – perhaps it’s

New to JRuby.
I am setting up a java shell and attempting to add in scripting
functionality, JRuby and Rhino.
After seeing this post I tried to set it up to run this via the JSR 223

shell =
puts shell
pid = shell.hp(‘exec jps | grep CommandLine’)
puts pid

Obviously doesn’t get to jhat yet. HP.hp is a little simple JRuby method
so that it can invoke back into the java shell. (Called HalfPipe)
rbs is the shell command for the JSR 223 interface.

rbs “/Volumes/mbvol/HalfPipe/Scripts/jhatMe.rb”
at org.jruby.embed.variable.Argv.updateARGV(
at org.jruby.embed.variable.Argv.retrieve(
at org.jruby.embed.jsr223.JRubyEngine.eval(
at org.jruby.embed.jsr223.JRubyEngine.eval(
at org.cmdline.cmds.rbs.main(
at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
at java.lang.reflect.Method.invoke(
at org.cmdline.psuedoGestalt.Runner.invoke(
at org.cmdline.psuedoGestalt.Runner.runStatic(
at org.cmdline.psuedoGestalt.Runner.runMain(

Previously, I was getting uninitialized errors for ARGV so I added this
ScriptEngine engine = factory.getEngineByName(“jruby”);
engine.put(ScriptEngine.ARGV,new String[] { “no args” });
Also tried with new Strint[0].

How should I properly handle ARGV?

I have a JIRB way of running as well based on googled demo code that
does this…
final RubyInstanceConfig config = new RubyInstanceConfig() {{

Would this be better?

I just noticed this isn’t giving me the application pid anyhow, grep
apparently loses it.
It should be extraced from…
exec jps
222 Jps
209 CommandLine

But not that relevant to the ARGV question. I can skip the grep and scan
the returned array myself.