Class preloading

[Gustav Åkesson]

Hi all,

Since we suffer from static initializers/fields, I can't see that AppCDS
would benefit. Also, as I interpret CDS is that it more or less "loads" all
the classes in the specified jar-files (specifying the jars is another
maintenance problem, whenever we introduce new modules/components). Our
system consists of multiple JVMs using different classes from shared
modules/components, and CDS would load classes which are not used which
would affect JIT, memory consumption etc.

These are also the reason for the topic of discussion here - having a
preloading of classes and static initializers/fields which bases its'
decision on previous JVM lifecycle.

- - - -

Fresh statistics for the first request after JVM start.

*No changes*
Client timeout (= more than 2.1sec)

*Preloading using Class.forName(className, false, classLoader)*
2045ms

*Preloading using Class.forName(className, true, classLoader)*
462ms


Please not that the statistics above is a bit different than reported in
the original mail since we have expanded the request's content.


Best Regards,
Gustav Åkesson


On Sun, Jan 3, 2016 at 8:36 AM, Ioi Lam <ioi.lam at oracle.com> wrote:

> 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
>>
>
>