Class preloading

Gustav Åkesson gustav.r.akesson at
Thu Dec 31 13:26:29 UTC 2015


I hope this is the appropriate mailing list, if not please advise.

I'm working in a telco system and in one of our R&D projects we experienced
significant problems when the system processed its' first request. The
first request took 1600ms and the second 50ms, and the latency of the first
request was unacceptable especially in case an unexpected restart is
performed during peak hours.

Quite obviously, classloading was to blame. The problem we saw was not
classloading itself, but the static initializers and initialization of
static fields. Both our own code and 3PPs make use of static, heavy and
reusable objects in order to improve performance - which of course are
initialized by the classloader. And to my experience, this idiom is quite
frequent. One common example is the thread-safe Holder idiom for singleton

Even though this issue is well-known, we had to come up with a remedy. What
I did is hatching the idea that before JVM shutdown, we store the currently
loaded classes on disk. At next start, before the JVM accepts any requests,
these classes are loaded again. The main idea is that classes which have
been loaded by a previous JVM lifecycle is likely to be loaded in the
subsequent. This trick resulted in the first request taking 50ms, i.e. as
short/long as the second one. We had no choice but to move forward with
this solution, which I think is sort of sad since this is somewhat of an
inherited issue with the dynamic classloading of Java.

Reason for sharing this scenario here is that I'd like to explore the
opportunity of bringing this as an optional JVM feature (-XX flag), but
obviously as a more builtin and refined construct. I reckon more folks have
similar kind of issues, but before proceeding with a JEP I'd like to get
some input and views on the matter.

In case the above proposal as such is not the way forward for the JVM as a
product, I think we need to figure out something else because we Java
server folks are really suffering because of classloading.

Happy new year & cheers,
Gustav Åkesson

More information about the hotspot-dev mailing list