So You Want To Write Your Own Benchmark

My JavaEdge 2008 presentation is now available on slideshare.net

So You Want To Write Your Own Benchmark

View SlideShare presentation or Upload your own. (tags: microbenchmarking benchmarking)

JavaEdge 2008

Last Thursday (18.12.2008) 6 months of hard work resulted wit the JavaEdge 2008 event which took place in Israel. JavaEdge is a yearly Java seminar conducted by AlphaCSP, which I proudly work for. This year we had more than 500 participants, 2 assembly speeches by Stephen Colebourne (keynote) and Frederic Simon, 3 tracks with 5 sessions each. Sessions where presented by AlphaCSP workers and guests including Alef Arendsen from SpringSource and Dmitry Jemerov from JetBrains. Sessions covered topics such as OSGi, Android, JavaFX, Java for the cloud, Comet, DSLs and more.

During his keynote speech, Stephen presented 10 possible language changes for JDK7, and asked the audience to vote on them. More than 300 people cast their votes. The detailed results are presented in Stephen's blog.

"java.lang.OutOfMemoryError: PermGen space" with a twist

There are a lot of posts out there about the "java.lang.OutOfMemoryError: PermGen space" exception. A good description of the problem can be found in Frank Kieviet's blog.
One of the main causes for this error is a classloader not being garbage collected when you undeploy an application. A few days ago I encountered this problem but with a certain twist causing it to become even worse.

It all started with JBoss servers suffering from PermGen bloat which lead eventually to a "java.lang.OutOfMemoryError: PermGen space" exception.
Analyzing a heap dump from one of the servers using jhat we saw a long list of about 2000 $Proxy classes which where the immediate suspects for the situation
















After some checking some of these proxies we could determine two things:

1. They have no instances
2. They are loaded by instances of JBoss RemotingClassLoader

Some more digging showed that there are 819 instances of the JBoss RemotingClassLoader all of them loading only $Proxy classes. This seemed to be a little odd so we used jmap with the "-permstat" option to look at the current status of one of the servers and what we got was a long list of JBoss RemotingClassLoaders - they where all dead !












OK, we have a list of dead classloaders loading proxy classes this is definitely the cause for the leak, but why?
Back to jhat we checked the reference chains to one of the proxies. The result showed a suspect that may be causing the leak: a static field named "classesToGetAndSetters" in Wicket's PropertyResolver class.












A quick pick into the Wicket source code discovered that classesToGetAndSetters is a map caching getters and setters. The problem is that Class objects are used as keys and that this is an unbounded cache with no eviction policy. Now, as long as you put "regular" (non Proxy) classes into this cache you will only encounter the usual classloader leak problem when unloading the application. This was already taken care by wicket, but we have a different problem.
In our case for each Proxy instance there is also a new $Proxy class filling up this cache. To add more complexity all these proxies where retrieved using JBoss remoting. A new RemotingClassLoader was created each time but never released since the cached $Proxy class is still referencing it.
The solution for such an issue is using a bound cache with some sort of eviction policy or something like google-collections ReferenceMap.