users@glassfish.java.net

Trying to understand why toplink creates so many persistent objects

From: <glassfish_at_javadesktop.org>
Date: Mon, 16 Jun 2008 12:59:10 PDT

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