Class preloading

[Ioi Lam]

Gustav,

I think what you are doing (forcing classes to be initialized during 
server start-up) is a common practice. Doing this in the user code would 
be the right thing to do. It will be difficult for the JVM to do this 
automatically for you. Imagine you have a custom class loader like this:

     ClassLoader myLoader = new MyLoader(....);
     myLoader.loadClass("Foo");
     myLoader.loadClass("Bar");

Even if the JVM knows (from past executions) that a class named "Foo" 
should be loaded and initialized at program start-up, it would not know 
how to find the myLoader to load such a class.

Yes, we could specialize something for the application class loader, but 
in general, the user program would be the right entity to be doing such 
things.

Thanks
- Ioi

On 1/4/16 6:36 AM, Gustav Åkesson 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 
> <mailto: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
>
>
>