Class preloading

Jeremy Manson jeremymanson at
Sun Jan 3 03:33:00 UTC 2016

Is this different from application class data sharing?

You will still have to run class initializers - anything that, for example,
reads the time of day or does something based on an IP address won't work


On Thu, Dec 31, 2015 at 5:26 AM, Gustav Åkesson <gustav.r.akesson at>

> Hi,
> 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
> instantiation.
> 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