Class preloading

[Ioi Lam]

Do you have statistics regarding how much time is spent in class loading 
vs the static initializers? How many classes are loaded during the 1600ms?

One quick thing to try is to run with -verify:none. This typically would 
reduce the class loading time by about half. If you don't see a 
significant reduction, then I would suspect that the bottleneck is not 
in class loading itself, but rather the amount of work done inside the 
static initializers.

- Ioi


On 12/31/15 5:26 AM, Gustav Åkesson wrote:
> 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