Well, but how to find out who is the bad guy? Which of the many plugins I have installed "killing me"? I was using Stack Trace, a cool application that lets you attach to eclipse and get a stack trace.
Most of the time the stack traces of the wild application ended in:
at java.lang.ClassLoader.defineClass1(Native Method)
at java.lang.ClassLoader.defineClass(Unknown Source)
at org.eclipse.osgi.internal.baseadaptor.DefaultClassLoader.defineClass(DefaultClassLoader.java:160)
at org.eclipse.osgi.baseadaptor.loader.ClasspathManager.defineClass(ClasspathManager.java:498)
at org.eclipse.osgi.baseadaptor.loader.ClasspathManager.findClassImpl(ClasspathManager.java:468)
at org.eclipse.osgi.baseadaptor.loader.ClasspathManager.findLocalClassImpl
Hmm, the class loader puts the class files in a special area of the garbage collector, (perm generation). The starving (100 % CPU and being really bad) seemed to be caused by not enough memory in the perm space. To fix this, I added
-vmargs -XX:MaxPermSize=128m
to the shortcut that starts eclipse. That solved the problem! The sun default seems to be 64MB (I could not find information for java1.5). But how much is the perm size really? How to find this out? Today, I found a blog entry by Igor Shabalov describing a cool tool called jconsole, that comes with jdk1.5.0, that allows you to inspect memory related information of your java applications life. All you have to do, it to add
-Dcom.sun.management.jmxremote
to the eclipse -vmargs
. Then you can attach to eclipse and see life the different garbage collection pools and the loaded classes and threads -- pretty cool...