Class loader memory leak in a Grails app

I have a grails app running on tomcat that seems to be leaking class loaders and after about 2 weeks of operation it throws OOME. I am however unable to figure out what is root cause of the issue. Any help on how to tackle this will be highly appreciated.

Grails Plugins Installed

app.grails.version=1.3.7
app.name=bm
app.servlet.version=2.4
app.version=0.1
plugins.database-migration=1.0
plugins.executor=0.3
plugins.export=0.9
plugins.google-visualization=0.5
plugins.hibernate=1.3.7
plugins.mail=1.0-SNAPSHOT
plugins.quartz=0.4.2
plugins.spring-security-core=1.2.1
plugins.tomcat=1.3.7

JMAP output

 num     #instances         #bytes  class name
----------------------------------------------
1:        140060       18764192  <constMethodKlass>
2:        164561       17114344  org.codehaus.groovy.runtime.metaclass.MetaMethodIndex$Entry
3:        140060       16817936  <methodKlass>
4:         14326       15583816  <constantPoolKlass>
5:        157629       14203608  [C
6:         14326       12833728  <instanceKlassKlass>
7:         71899       10928648  java.lang.reflect.Method
8:         12865        9810400  <constantPoolCacheKlass>
9:        155186        9471320  <symbolKlass>
10:         28791        9364696  [B
11:        164650        7903200  java.util.concurrent.locks.ReentrantLock$NonfairSync
12:        164496        7895808  java.util.concurrent.ConcurrentHashMap$Segment
13:        154748        7427904  java.util.HashMap$Entry
14:        137621        7235504  [Ljava.lang.Object;
15:        178058        7122320  java.lang.String
16:        164496        5876008  [Ljava.util.concurrent.ConcurrentHashMap$HashEntry;
17:         25224        5322656  [Ljava.util.HashMap$Entry;
18:         16359        4774824  [Lorg.codehaus.groovy.util.ComplexKeyHashMap$Entry;
19:          6456        3368704  <methodDataKlass>
20:         69962        3358176  org.codehaus.groovy.util.SingleKeyHashMap$Entry
21:         59890        3353840  java.lang.ref.SoftReference
22:         69222        3322656  java.lang.ref.WeakReference
23:         31530        3026880  java.beans.MethodDescriptor
24:         22579        2890112  java.lang.reflect.Field
25:           897        2824728  [Lorg.codehaus.groovy.runtime.metaclass.MetaMethodIndex$Entry;
26:         15006        2761104  java.lang.Class
27:         45281        2592272  [I
28:         23921        2487784  org.codehaus.groovy.reflection.CachedMethod
29:         46947        1877880  java.util.ArrayList
30:         58290        1865280  org.codehaus.groovy.util.FastArray
31:         21968        1832888  [[I
32:         56895        1792872  [Ljava.lang.Class;
33:            34        1681456  [Lorg.apache.commons.collections.map.AbstractHashedMap$HashEntry;
34:         46489        1661760  [Ljava.lang.String;
35:         10267        1562376  [Ljava.util.concurrent.ConcurrentHashMap$Segment;
36:         12511        1501320  java.lang.reflect.Constructor
37:         30817        1479216  java.util.concurrent.ConcurrentHashMap$HashEntry
38:         17869        1248784  [S
39:         19447        1244608  java.util.HashMap
40:         20885        1169560  groovy.lang.MetaBeanProperty

I wonder if the executor plugin is the culprit due to the high number of concurrentHashMap entries. I checked out the number of instances for my own classes using jmap at different times and they don't seem to be increasing. How do I go about resolving this, even if you can provide me an "approach to tackle" this issue, it will be great.

Upvotes: 2