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.

Chris


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/ClassCache$OneShotClassLoader@0x00000007e1cda048
0x00000005eab7a748 6 179928 0x00000005e02eb350 dead
org/jruby/util/ClassCache$OneShotClassLoader@0x00000007e1cda048
0x00000005e161f968 6 178192 0x00000005e02eb350 dead
org/jruby/util/ClassCache$OneShotClassLoader@0x00000007e1cda048
0x00000005eab85750 7 183624 0x00000005e02eb350 dead
org/jruby/util/ClassCache$OneShotClassLoader@0x00000007e1cda048

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

this
0x00000005e93091a0 4 16056 0x00000005eab76720 dead
org/jruby/util/JRubyClassLoader@0x00000007e0e40cf0
0x00000005e2a296a8 7 100112 0x00000005e2a296f8 dead
org/jruby/util/JRubyClassLoader@0x00000007e0e40cf0

Couple of these have a lot of references

0x00000005e02eb350 4927 20736792 0x00000005e0076060
dead org/apache/catalina/loader/WebappClassLoader@0x00000007e0c5a1d0
0x00000005e0076060 959 7476160 0x00000005e001c000 dead
org/apache/catalina/loader/StandardClassLoader@0x00000007e06d1af0

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

0x00000005e0450b78 1517 7110264 0x00000005e02eb350 dead
org/jruby/util/JRubyClassLoader@0x00000007e0e40cf0

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:
http://blog.headius.com/2010/07/browsing-memory-jruby-way.html
perhaps it’s helpful.

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

Have you seen this post:
http://blog.headius.com/2010/07/browsing-memory-jruby-way.html – perhaps it’s
helpful.

Hello,
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
interface.

jhatMe.rb
shell = HP.new
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.
So,

rbs “/Volumes/mbvol/HalfPipe/Scripts/jhatMe.rb”
#HP:0x1d743b8
[System.in:4:CommandLine
]
java.lang.NullPointerException
at org.jruby.embed.variable.Argv.updateARGV(Argv.java:169)
at org.jruby.embed.variable.Argv.retrieve(Argv.java:158)
at
org.jruby.embed.variable.VariableInterceptor.retrieve(VariableInterceptor.java:153)
at
org.jruby.embed.internal.BiVariableMap.retrieve(BiVariableMap.java:386)
at
org.jruby.embed.internal.EmbedEvalUnitImpl.run(EmbedEvalUnitImpl.java:122)
at org.jruby.embed.jsr223.JRubyEngine.eval(JRubyEngine.java:130)
at org.jruby.embed.jsr223.JRubyEngine.eval(JRubyEngine.java:158)
at org.cmdline.cmds.rbs.main(rbs.java:62)
at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
at
sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:57)
at
sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
at java.lang.reflect.Method.invoke(Method.java:601)
at org.cmdline.psuedoGestalt.Runner.invoke(Runner.java:183)
at org.cmdline.psuedoGestalt.Runner.runStatic(Runner.java:210)
at org.cmdline.psuedoGestalt.Runner.runMain(Runner.java:202)
at org.cmdline.psuedoGestalt.Runner.run(Runner.java:124)

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() {{
setInput(console.getIn());
setOutput(System.out);
setError(System.out);
setArgv(args);
}};

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
145
209 CommandLine

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