yes those are the things that are generated:
private static synchronized String generateName(boolean isConstructor,
boolean forSerialization)
{
if (isConstructor) {
if (forSerialization) {
int num = ++serializationConstructorSymnum;
return
"sun/reflect/GeneratedSerializationConstructorAccessor" + num;
} else {
int num = ++constructorSymnum;
return "sun/reflect/GeneratedConstructorAccessor" + num;
}
} else {
int num = ++methodSymnum;
return "sun/reflect/GeneratedMethodAccessor" + num;
}
}
the only thing i dont get is that for you the forSerialization flag
should be true (at least the stack trace you shown us)
So for your serialization thing you should have:
GeneratedSerializationConstructorAccessor1 or something..
But i guess you have classes that generate those special constructors
even more also for not specific to serialization.
On Fri, Jul 23, 2010 at 14:12, James Carman <[email protected]> wrote:
> 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]
>
>
---------------------------------------------------------------------
To unsubscribe, e-mail: [email protected]
For additional commands, e-mail: [email protected]
