Hi,
Glassfish v2ur2
My application is routinely exhausting its perm generation space. Looking at the jhat output, it seems that this is caused by toplink (essentials). I have shared caching enabled, using the default cache type. The jhat histo output reveals the following:
most used classes
num #instances #bytes class name
----------------------------------------------
1: 18376 23099216 [B
2: 191301 22320592 [C
3: 140125 17288376 <constMethodKlass>
4: 179672 12936384 oracle.toplink.essentials.internal.identitymaps.HardCacheWeakIdentityMap$ReferenceCacheKey
5: 140125 11215856 <methodKlass>
6: 209460 9522896 <symbolKlass>
7: 12161 7272192 <constantPoolKlass>
8: 181116 7244640 java.math.BigInteger
9: 179763 5752416 oracle.toplink.essentials.internal.helper.ConcurrencyManager
10: 12161 5499984 <instanceKlassKlass>
11: 227573 5461752 java.lang.String
12: 209595 5030280 java.util.Hashtable$Entry
13: 219534 4878720 [Ljava.lang.Object;
14: 189084 4538016 java.util.Vector
15: 180714 4337136 java.lang.ref.WeakReference
16: 179697 4312728 oracle.toplink.essentials.internal.helper.linkedlist.LinkedNode
17: 10220 4311856 <constantPoolCacheKlass>
18: 195495 4229672 [I
19: 71408 3427584 com.sun.tools.javac.zip.ZipFileIndexEntry
20: 2610 2511808 [Ljava.util.Hashtable$Entry;
21: 7721 2189056 <methodDataKlass>
22: 57290 1374960 java.util.HashMap$Entry
23: 13005 1248480 java.lang.Class
24: 10651 1162024 [Ljava.util.HashMap$Entry;
25: 16942 1110352 [S
26: 19364 908992 [[I
27: 17247 551904 java.util.TreeMap$Entry
28: 18353 440472 java.util.ArrayList
29: 9046 434208 com.sun.tools.javac.zip.ZipFileIndex$DirectoryEntry
30: 4597 367760 java.lang.reflect.Method
31: 8863 354520 java.util.HashMap
32: 10305 329760 java.lang.ref.SoftReference
33: 5807 325192 org.apache.tomcat.util.buf.MessageBytes
34: 5760 322560 oracle.toplink.essentials.internal.indirection.UnitOfWorkQueryValueHolder
35: 153 287840 [Lcom.sun.tools.javac.zip.ZipFileIndexEntry;
36: 6876 275040 org.apache.tomcat.util.buf.ByteChunk
37: 815 260800 <objArrayKlassKlass>
38: 6072 242880 org.apache.tomcat.util.buf.CharChunk
39: 6524 208768 java.util.LinkedHashMap$Entry
40: 5038 201520 oracle.toplink.essentials.indirection.IndirectList
41: 3030 193920 com.mysql.jdbc.ConnectionPropertiesImpl$BooleanConnectionProperty
42: 5035 161120 javax.management.MBeanAttributeInfo
43: 6542 157008 java.util.LinkedList$Entry
44: 2339 149696 oracle.toplink.essentials.internal.identitymaps.CacheKey
45: 2858 137184 java.util.TreeMap
46: 3602 134328 [Ljava.lang.String;
47: 2052 131328 java.lang.reflect.Constructor
48: 4070 130240 oracle.toplink.essentials.internal.indirection.QueryBasedValueHolder
49: 14278 114224 java.lang.Object
50: 1756 112384 com.sun.org.apache.commons.modeler.AttributeInfo
51: 6864 109824 oracle.toplink.essentials.indirection.ValueHolder
52: 4383 105192 javax.management.MBeanParameterInfo
53: 6304 100864 java.lang.Long
I looked for my JPA classes in the histogram and found that the ones that taking the most space were these:
56: 1129 90320 org.webonweb.runtime.impl.repository.db.jpa.DbServiceParameter
75: 676 54080 org.webonweb.runtime.impl.repository.db.jpa.DbItem
Clearly my use of the cache does not explain the leak. This looks a lot like abnormal behavior on the part of toplink.
Thanks in advance for the pointers.
[Message sent by forum member 'jbelis' (jbelis)]
http://forums.java.net/jive/thread.jspa?messageID=280562