Here's an interesting error message from jvisualvm: *** Profiler engine warning: class sun.reflect.GeneratedConstructorAccessor1 that should be instrumented is not loaded by target VM *** Requested classloader: sun.reflect.delegatingclassloa...@7dc5ddc9, its class = class sun.reflect.DelegatingClassLoader, index = 542, hashcode = 2110119369 *** Profiler engine warning: target VM cannot load class to instrument sun.reflect.GeneratedConstructorAccessor1 *** probably it has been unloaded recently
Sounds like we're on the right track, perhaps? On Fri, Jul 23, 2010 at 7:54 AM, Johan Compagner <[email protected]> wrote: > as far as i see now if i look that the stacktrace: > > java.io.ObjectStreamClass.<init>(ObjectStreamClass.java:413) > java.io.ObjectStreamClass.lookup(ObjectStreamClass.java:310 > > so ObjectSTreamClass.lookup call there the constructor of ObjectStreamClass > lookup does check for caches but those are soft caches so these can be > cleared. > It can mean 2 things, or somehow you have constantly different classes > (proxies or cglib generated other stuff?) > or the softcaches are cleared quite often > they kind of do that quite often, SoftReferences are NOT only cleared > when the jvm needs more mem but also much sooner! > You can set this system property: -XX:SoftRefLRUPolicyMSPerMB=3600000 > that will result in a much longer live softreference... > > Because there is constantly a ObjectStreamClass generated i think you > are then hitting the MethodAccessorGenerator: > > private MagicAccessorImpl generate(final Class declaringClass, > String name, > Class[] parameterTypes, > Class returnType, > Class[] checkedExceptions, > int modifiers, > boolean isConstructor, > boolean forSerialization, > Class serializationTargetClass) > > and that is constructing byte code on the fly and calling defineClass > on it which results in a new class all the time that is a > implementation of MagicAccessorImpl > that then is a "fake" constructor for your first none serializable > class (that didnt have one on its own) > > > > > On Fri, Jul 23, 2010 at 13:26, James Carman <[email protected]> > wrote: >> I am not using intern() anywhere. Who knows if any of the gazillion >> third-party libraries are using it, though. Time to fire up jmap >> >> On Fri, Jul 23, 2010 at 7:24 AM, Thomas Kappler >> <[email protected]> wrote: >>> On 07/22/10 20:30, James Carman wrote: >>>> >>>> Guys, our production server is running into an error from time to >>>> time. I get the below stack trace after the site has been running for >>>> a while. It's not running in development mode. It's running in >>>> deployment mode. Any thoughts? >>> >>> Are you by chance using String.intern()? That is a candidate for filling up >>> the PermGen space. >>> >>> As Andreas noted, the stack trace can be completely irrelevant to the reason >>> for running out of memory. >>> >>> -- Thomas >>> >>> -- >>> ------------------------------------------------------------------- >>> Thomas Kappler [email protected] >>> Swiss Institute of Bioinformatics Tel: +41 22 379 51 89 >>> CMU, rue Michel Servet 1 >>> 1211 Geneve 4 >>> Switzerland http://www.uniprot.org >>> ------------------------------------------------------------------- >>> >>> --------------------------------------------------------------------- >>> To unsubscribe, e-mail: [email protected] >>> For additional commands, e-mail: [email protected] >>> >>> >> >> --------------------------------------------------------------------- >> To unsubscribe, e-mail: [email protected] >> For additional commands, e-mail: [email protected] >> >> > > --------------------------------------------------------------------- > To unsubscribe, e-mail: [email protected] > For additional commands, e-mail: [email protected] > > --------------------------------------------------------------------- To unsubscribe, e-mail: [email protected] For additional commands, e-mail: [email protected]
