Initializing all Java classes at Start-Up

Jean-Marie Dautelle writes "Java classes are initialized at first-use only which can introduce significant runtime delays detrimental to real-time or games applications (for which accurate scheduling is often required). To solve this problem, the latest open-source Javolution library supports initialization of all Java classes at start-up (e.g. javolution.lang.ClassInitializer.initializeAll(); // Initialize runtime classes (rt.jar) and all classes in classpath). Note: Runtime class initialization (rt.jar) takes typically a few seconds and about 3 Mbytes of memory."

Comments

Benefits for anything other than games?

[Carl Rosenberger]

"A few seconds" and 3MB of memory for rt.jar sound nice but I wonder how timings and memory consumption would look like with a couple of more libraries in the CLASSPATH, how about a full Eclipse environment?

The problem with Java startup times is that every Java app loads it's own complete runtime environment. This is not easy to fix, since many apps depend on the fact that they get their own.

Re:Benefits for anything other than games?

[breadbot]

Sun has been talking about shared VMs for a while now -- I can't remember if it's scheduled for version 6 or 7 -- the object space would be partitioned among the running Java "processes", but only one JVM would be necessary. It would improve startup times, memory consumption, etc. They could all share one instance of rt.jar, for example, assuming it was process-safe (it may not be now, but fixing it would be something Sun would have to do for the actual release). I don't see it listed in the Java 6 (Mustang) notes (for example here), so I would guess that it's slated for versin 7 (Dolphin).

Very, very rarely a good idea

[/ASCII]

There are two reasons why lazy initialization is almost always the better solution:

• Not all classes are used. Why pay a memory and performance penalty for having e.g. the Java2d API installed if your application never uses it?
• Startup time will suffer. A 3 second startup penalty for only the bare minimum runtime, and probably much more for any non-trivial application is a huge deal.

The advantage of doing eager initialization is predictability, and in the case where almost all classes get initialized sooner or later (which would be very rare considering the size of the Java API) a slight performance increase.

Maybe some kinds of games would benefit from this, but almost all other applications would benefit from more lazy initialization, not less.

Shameless Plug or Valid Selfpromotion?

[dorkygeek]

Let's see. Submitter of story: Jean-Marie Dautelle. Javolution project owner: Jean-Marie Dautelle.

Re:Shameless Plug or Valid Selfpromotion?

[d-rock]

Well, Jean-Marie *has* contributed a lot to the Java community. While this particular post may look trivial or not super important, the Javolution framework does have a lot of nice features and is RTSJ (real-time Java) compliant. He's also contributed a lot to JScience, which is another interesting framework for scientific calculations.

BTW, a lot of realtime Java has to do with deterministic behavior, and lazy initialization is non-deterministic. I don't think the main point here is to save a little bit of time by doing the load up front, but rather to get deterministic behavior from the system later on. For instance, let's say I have a class that normally take 20us for the constructor to run, but takes 15ms to load the class. If I'm expecting to be able to allocate a new instance of this class inside a method that has a maximum run time of 100us, then the system will fail if lazy initialization takes place. If that means I just missed a whole bunch of sensor readings, or that motor ran longer than it was supposed to, it could have some very bad consequences.

If you're interesting in learning about real time systems, or about real time Java in particular, I highly recommend the NIST's report on requirements for real time Java:

http://www.itl.nist.gov/div897/ctg/real-time/intro .html

Derek

Speding up Java Load Times

[Sweep The Leg]

I speed up my java load times by using this tecnique that I like to call C++.

On a more serious note, one of the problems with load times I have noticed in a lot of Java is that people unnecessarily include namespaces where they don't need/use them. Sometimes there's no reason to go into another library when there's an equivalent function in one you're already using and there's certainly no need to reference things you don't use. That also creates a design problem in addition to the performance issue IMO because although it's not hurting too bad, it's a violation of least privilege.

This post reminds me of some other related problems that occur in other languages both design and performance related. Although the issue with .NET is somewhat different, the design part is still the same. It gets worse in VB.NET (please don't start flaming) where people can have project level imports. It even bothered me in C++ when someone would lets say remove functionality but leave all the imports/#define behind. Today I came accross this problem in ASP.NET an webpage:

imports System.Web.UI (only namespace used)
imports System.Text (not used!)
imports System.XML.Serialization (not used!)
imports System.Threading (not used!)