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

Thread view:

JB - 01 Nov 2006 16:03 GMT

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

Reply to this Message

Thomas Hawtin - 01 Nov 2006 17:17 GMT

> 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

Reply to this Message

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

Free Magazines