How to prevent sun.reflect.GeneratedSerializationConstructorAccessor from being unloaded at full gc

J

JB

Experts,

in an application I'm using serialization of big data structures. For
deserialization purpose, the VM seems to generate and load classes (see
subject), which takes it some 100 milliseconds. Unfortunately, when a
full gc occurs, these classes get unloaded, resulting in the need of
regenerating and loading them the next time a serialized data structure
is accessed.

My java -version is 1.5.0_07-b03
Loading and unloading of these classes have been tracked by
"-verbose:class -verbose:gc"

My questions are:

1. Why are these classes generated? I'd like to understand this
concept, but can't find any information about it.
2. How can I prevent the garbage collector from unloading them?

Note that -Xnoclassgc doesn't help. The classes are not unloaded, but
nevertheless newly generated and loaded the next time an object is
deserialized.

Thanks in advance
JB
 
T

Thomas Hawtin

JB said:
in an application I'm using serialization of big data structures. For
deserialization purpose, the VM seems to generate and load classes (see
subject), which takes it some 100 milliseconds. Unfortunately, when a
full gc occurs, these classes get unloaded, resulting in the need of
regenerating and loading them the next time a serialized data structure
is accessed.
1. Why are these classes generated? I'd like to understand this
concept, but can't find any information about it.

These classes are part of the reflection mechanism. Since around Java
1.3 reflection has been implemented by generating classes to perform the
access. It's much faster use, but takes longer to create and upsets the
permanent generation.

Serialisation uses them to read/write fields, execute methods
(readObject, writeObject, readObjectNoData, readResolve) and call the
non-serialisable base class constructor (this last code is not verifiable).

It is highly unpleasant and not advisable to go through your code using
transient, readObject/writeObject and possibly changing data structures
to be more use a smaller set to classes.
2. How can I prevent the garbage collector from unloading them?

Note that -Xnoclassgc doesn't help. The classes are not unloaded, but
nevertheless newly generated and loaded the next time an object is
deserialized.

Now that's more difficult. You don't just want to prevent them
unloading, but you want to keep the private objects that reference the
reflection objects from the internal serialisation class description
cache. I'm not sure that is possible.

They should be held by soft references. IIRC, soft references are
generally held for one second for every megabyte of free memory after GC
(maximum memory being determined by -Xmx in the server VM and by the
current heap space by the client VM). So if you are seeing this problem,
I assume you are very low on memory. I guess the OutOfMemoryError
trigger and SoftReference clearing don't work entirely cooperatively.

Therefore, the cure is probably more memory. Set -Xms and -Xmx higher.

Tom Hawtin
 
Joined
Nov 10, 2010
Messages
1
Reaction score
0
I was stuck in a similar issue and wrote down an article with my experience at http: // anshuiitk.blogspot.com/2010/11/ excessive-full-garbage-collection.html
 

Members online

Forum statistics

Threads
473,997
Messages
2,570,241
Members
46,831
Latest member
RusselWill

Latest Threads

Top