GeneratedMethodAccess Memory Cost Problem

[lightning]

We have some tomcat running day and night.RMI client, spring,
hibernate, dwr .. are used in the webapp.
After a certain period of time, we found quiet a lot of:

[Unloading class
sun.reflect.GeneratedSerializationConstructorAccessor1051]
[Unloading class
sun.reflect.GeneratedSerializationConstructorAccessor1054]
[Unloading class
sun.reflect.GeneratedSerializationConstructorAccessor1049]
[Unloading class sun.reflect.GeneratedMethodAccessor7715]
[Unloading class sun.reflect.GeneratedMethodAccessor7719]
[Unloading class sun.reflect.GeneratedMethodAccessor7718]
[Unloading class sun.reflect.GeneratedMethodAccessor7717]
[Unloading class sun.reflect.GeneratedMethodAccessor7716]
[Unloading class sun.reflect.GeneratedMethodAccessor7720]
[Unloading class sun.reflect.GeneratedMethodAccessor7816]
[Unloading class
sun.reflect.GeneratedSerializationConstructorAccessor10

in the log. Just at that time, the app become unstable and even out of
memory for thread creating. Maybe these fill up the Perm Space and
make jvm have to cost more resources to unload all these unused
classes....to free memory.

I search the web for info and know that these classes are loading when
serializing and deserializing happens, so it must be caused by rmi.Why
does rmi have to make so many classes to do that???? Why not reuse??

Does our code meets any pitfalls?

 

[Daniel Pitts]

We have some tomcat running day and night.RMI client, spring,
hibernate, dwr .. are used in the webapp.
After a certain period of time, we found quiet a lot of:

[Unloading class
sun.reflect.GeneratedSerializationConstructorAccessor1051]
[Unloading class
sun.reflect.GeneratedSerializationConstructorAccessor1054]
[Unloading class
sun.reflect.GeneratedSerializationConstructorAccessor1049]
[Unloading class sun.reflect.GeneratedMethodAccessor7715]
[Unloading class sun.reflect.GeneratedMethodAccessor7719]
[Unloading class sun.reflect.GeneratedMethodAccessor7718]
[Unloading class sun.reflect.GeneratedMethodAccessor7717]
[Unloading class sun.reflect.GeneratedMethodAccessor7716]
[Unloading class sun.reflect.GeneratedMethodAccessor7720]
[Unloading class sun.reflect.GeneratedMethodAccessor7816]
[Unloading class
sun.reflect.GeneratedSerializationConstructorAccessor10

in the log. Just at that time, the app become unstable and even out of
memory for thread creating. Maybe these fill up the Perm Space and
make jvm have to cost more resources to unload all these unused
classes....to free memory.

I search the web for info and know that these classes are loading when
serializing and deserializing happens, so it must be caused by rmi.Why
does rmi have to make so many classes to do that???? Why not reuse??

It probably does re-use, if it can. Anyway, just because those are the
classes that are being cleaned up, doesn't mean they are the classes
causing the problems. As a matter of fact, since they *are* being
cleaned up, they probably *aren't* the problem source.

Does our code meets any pitfalls?

I suggest using a memory profiler to see what *is* actually taking up
space. There are a lot of things that could be going wrong.

Also note, that if you do a lot of hot-deploys, you are likely to see
this problem too. Try doing a restart for deployments, and see if that
fixes your problem.

 

[huang xiaofei]

hi Daniel:

Thanks for your reply.
We never use hot-deploys.
The problem is if these xxxxxAccessorXXX keep increasing, more or
less, the perm space will be used up.
What can prevent the app from using more and more XXXAccessor ???

 

[Daniel Pitts]

hi Daniel:

Thanks for your reply.
We never use hot-deploys.
The problem is if these xxxxxAccessorXXX keep increasing, more or
less, the perm space will be used up.
What can prevent the app from using more and more XXXAccessor ???

Just because they are collected, doesn't mean they are the thing that is
being packratted!

Provide an SSCCE, or use a profiler. We can't otherwise help you.

 

[huang xiaofei]

hi,
I think it's caused by this bug:

Bug fix: delayed garbage collection
In previous releases, bug 6232010 could cause serializable classes and
subclasses of ObjectOutputStream and ObjectInputStream to be strongly
referenced long after their use in a serialization operation, thus
possibly delaying garbage collection of their defining class loaders
indefinitely. Internal caches in the serialization implementation have
been restructured to fix this bug.