Class preloading

[Jiangli Zhou]

Hi Gustav,

Thanks for sharing the data. In the old Java ME days, we had similar support in the VM (CVM). The server VM can pre-load and pre-initializae a set of classes. The pre-loaded and initialized classes reside in shared memory, so client/child VM spawned by the server VM can access those classes. However not all classes can be pre-initialized. For example, classes that creates Thread should not be pre-initialized.

CDS does not archive all classes in a specified jar file. It archives a set of classes, which can be adjusted based on the usage requirement. As of today, CDS does not support pre-initializing archived classes. So you are right on that part.

Thanks,
Jiangli

> On Jan 4, 2016, at 6:36 AM, Gustav Åkesson <gustav.r.akesson at gmail.com> wrote:
> 
> 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
>>> 
>> 
>>