Why is the JVM running slow?

Question

What exactly makes the JVM (in particular, the Sun implementation) work slower than other runtimes such as CPython? My impression was that it was mainly related to loading downloadable libraries, regardless of whether they were needed or not, but it looked like it shouldn't take 10 years.

Think about it, how does the JVM start time compare to the CLR on Windows? How about Mono CLR?

UPDATE: I am particularly interested in the case of using small utilities connected together, as is customary in Unix. Is Java suitable for this style? Regardless of what Java starts up at the initial stage, is it summed up for each Java process, or does the overhead really only appear for the first process?

Answer 1

Here is what Wikipedia has to say on this subject (with some links).

It seems that most of the time only loading data (classes) from the disk is taken (i.e. start time - I / O binding).

Answer 2

Just note some solutions:

There are two mechanisms that can speed up the start of the JVM. The first one is the class data exchange mechanism, which has been supported since the Java 6 Update 21 update (only from the HotSpot client VM and only with the serial garbage collector, as far as I know)

To activate it, you need to install -Xshare (in some implementations: -Xshareclasses ).

More on the feature you can visit: Passing class data

The second mechanism is the Java Quick Starter. This allows you to preload classes at OS startup; see Java Quick Starter for more details.

Answer 3

Running a trivial Java application with the JVM client 1.6 (Java 6) seems instant on my machine. Sun tried to configure the client JVM to start faster (and the default client JVM), so if you don't need a lot of extra jar files, the start should be quick.

Answer 4

If you are using Sun HotSpot for x86_64 (64 bit compiled), note that the current implementation only works in server mode, that is, it precompiles each class that loads with full optimization, while the 32-bit version also supports the mode a client, which usually delays optimization and optimizes only part of the processor, but has a faster startup time.

See for example:

• http://en.wikipedia.org/wiki/64-bit#32_vs_64_bit
• http://java.sun.com/docs/hotspot/HotSpotFAQ.html#64bit_compilers

At the same time, at least on my machine (Linux x86_64 with a 64-bit kernel), the 32-bit version of HotSpot supports both client and server modes (via the -client and -server flags), but the server mode is used by default. and the 64-bit version only supports server mode.

Answer 5

It really depends on what you do during startup. If you run the Hello World application, it takes 0.15 seconds on my machine.

However, Java is better suited to act as a client or server / service, which means that startup time is not as important as connection time (about 0.025 ms) or round-trip time response time (<0.001 ms).

Answer 6

There are several reasons:

• a lot of jar to download
• validation (make sure the code doesn't do evil things)
• JIT (compile time only) overhead

I'm not sure about the CLR, but I think this is faster because it caches its own version of assemblies the next time (so this is not needed by JIT). CPython runs faster because it is an interpreter, and IIRC does not do JIT.

Answer 7

In addition to the words already mentioned (loading classes, for example, from compressed JARs); working in interpreted mode before HotSpot compiles frequently used bytecode; and compiling HotSpot, there are also quite a few one-time initializations performed by the JDK classes themselves. Many optimizations are performed in favor of longer systems where startup speed is less worrying.

As for unix-style connecting, you certainly DO NOT want to start and restart the JVM several times. It will not be effective. Most likely, the tool chain should occur in the JVM. It cannot be easily mixed with tools other than Java Unix, with the exception of running such tools from the JVM.

Answer 8

All virtual machines with a rich type system, such as Java or CLR, will not be perfect compared to less rich systems such as those in C or C ++. This is largely because much happens in the virtual machine, many classes are initialized and required by the working system. Snapshots of the initialized system really help, but it's still worth loading that image back into memory, etc.

A simple greeting class, created in the style of one ruler class with a basic one, requires a lot of loading and initialization. Class checking requires a lot of validation and dependency checking, which will cost time and many CPU instructions. On the other hand, program C will not execute any of them and will contain several instructions and then call the printer function.