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]
