Why is the JVM slow to start?

Question

What exactly makes the JVM (in particular, Sun's implementation) slow to get running compared to other runtimes like CPython? My impression was that it mainly has to do with a boatload of libraries getting loaded whether they're needed or not, but that seems like something that shouldn't take 10 years to fix.

Come to think of it, how does the JVM start time compare to the CLR on Windows? How about Mono's CLR?

UPDATE: I'm particularly concerned with the use case of small utilities chained together as is common in Unix. Is Java now suitable for this style? Whatever startup overhead Java incurs, does it add up for every Java process, or does the overhead only really manifest for the first process?

Tagging with subjective. "Slow" is a subjective description. — Martin OConnor, May 09 '09 at 22:01
@Martin OConnor: "slow" is subjective but this question is not. — Zifre, May 09 '09 at 22:11
AFAIK, the V8 Javascript engine from Google for Node.js takes about 30 milliseconds. I doubt that's much slower than the JVM. It appears the JVM takes about 70 ms. http://tinyurl.com/phkwn45 — Alexander Mills, May 28 '15 at 03:22

score 23 · Accepted Answer · edited Mar 30 '15 at 17:18

23

Here is what Wikipedia has to say on the issue (with some references).

It appears that most of the time is taken just loading data (classes) from disk (i.e. startup time is I/O bound).

edited Mar 30 '15 at 17:18

Matej Kormuth

2,139
3
35
52

answered May 09 '09 at 22:07

Naaff

9,213
3
38
43

3

One clarification: it's not just (or perhaps so much) disk I/O, but finding classes from within jars (wars, ears), which are zip archives. Extraction takes CPU, but especially if they are compressed. – StaxMan May 10 '09 at 01:53
5

CPU time to decompress is minimal. Indeed, stackoverflow itself uses compression as a performance optimisation, and compression is massively more expensive than decompressions. – Tom Hawtin - tackline May 10 '09 at 03:19
Also rt.jar isn't important for the client HotSpot, which defaults to using the half-shared classes.jsa file. – Tom Hawtin - tackline May 10 '09 at 03:30
2

@Tom: CPU time to decompress a 2kb class file: minimal. CPU time to decompress a 30mb class file to read a 2kb class file: significant. – Seun Osewa Oct 10 '09 at 14:23
6

@Seun a jar file uses zip compression, there is no need to decompress the whole archive for one file, each entry (file) is compressed independent of other entries. – josefx Apr 08 '10 at 13:38
1

I don't get why they don't keep a persistent (i.e. saved across reboots) cache of commonly-used classes, and just check the timestamps of the source jars when a JVM launches. It seems like they could load that at startup and catch 80% of the classes that end up being used by most apps. Well, I guess they know what they're doing. – intuited Sep 21 '10 at 05:09
@josefx No need to decompress the whole file -- yes. But for ZIP you still need to _read_ the whole content before the entry in ZIP archive to find the entry you need. And IO is usually much slower than CPU to decompress, so in the end it's still almost as slow as decompressing. – Dzmitry Lazerka Jun 26 '17 at 21:47
An example of a truly seekable compression is LZO. – Dzmitry Lazerka Jun 26 '17 at 21:49
2

@DzmitryLazerka Zip archives end with a central directory entry, which lists both entry names and their offsets. You jump to the end, read through the directory and jump to the entry you need. – josefx Jun 28 '17 at 16:08
Hmm, yes, you're right. I have always worked with InputStreams (no seek support), but Zip's central directory is at the end of file. – Dzmitry Lazerka Jun 29 '17 at 19:50

score 8 · Answer 2 · answered Feb 04 '13 at 07:53

Just to note some solutions:

There are two mechanisms that allow to faster startup JVM. The first one, is the class data sharing mechanism, that is supported since Java 6 Update 21 (only with the HotSpot Client VM, and only with the serial garbage collector as far as I know)

To activate it you need to set -Xshare (on some implementations: -Xshareclasses ) JVM options.

To read more about the feature you may visit: Class data sharing

The second mechanism is a Java Quick Starter. It allows to preload classes during OS startup, see: Java Quick Starter for more details.

The java quick starter link is dead :/ – Ludwik May 23 '20 at 14:08 — Ludwik, May 23 '20 at 14:08

score 5 · Answer 3 · answered May 09 '09 at 22:22

5

Running a trivial Java app with the 1.6 (Java 6) client JVM seems instantaneous on my machine. Sun has attempted to tune the client JVM for faster startup (and the client JVM is the default), so if you don't need lots of extra jar files, then startup should be speedy.

answered May 09 '09 at 22:22

jdigital

11,926
4
34
51

3

Whatever condition it is, jvm is still the vm that has slowest startup. You may find it fast enough on certain grade of machine and for certain size of application. But still its startup time is comparably inarguably slow. – Sake May 10 '09 at 07:50
I think GUI apps are primarily what gave Java the impression of being slow...having to load a buttload of AWT and Swing classes is probably what makes it take at least one second. – Andy Mar 04 '15 at 16:07

Paggas · Answer 4 · 2009-05-09T23:25:07.253

4

If you are using Sun's HotSpot for x86_64 (64bit compiled), note that the current implementation only works in server mode, that is, it precompiles every class it loads with full optimization, whereas the 32bit version also supports client mode, which generally postpones optimization and optimizes the most CPU-intensive parts only, but has faster start-up times.

See for instance:

That being said, at least on my machine (Linux x86_64 with 64bit kernel), the 32bit HotSpot version supports both client and server mode (via the -client and -server flags), but defaults to server mode, while the 64bit version only supports server mode.

edited May 09 '09 at 23:25

answered May 09 '09 at 23:12

Paggas

1,851
3
15
15

Are you sure your info is correct: I haven't heard of a (modern) Sun JVM that would done full JIT'ing for all classes? And server mode definitely does NOT do this on most systems. Difference between client and server modes has more to with different config settings, like threshold used for JIT inlining. – StaxMan May 10 '09 at 01:55
Server HotSpot doesn't do compilation until 10,000 iterations. Client does it at 1,500. However, the server is implemented somewhat differently (two instead of one intermediate representations, IIRC). – Tom Hawtin - tackline May 10 '09 at 03:22

score 3 · Answer 5 · edited Feb 11 '15 at 20:35

3

It really depends on what you are doing during the start up. If you run Hello World application it takes 0.15 seconds on my machine.

However, Java is better suited to running as a client or a server/service which means the startup time isn't as important as the connection time (about 0.025 ms) or the round trip time response time (<< 0.001 ms).

edited Feb 11 '15 at 20:35

gvlasov

18,638
21
74
110

answered May 10 '09 at 07:30

Peter Lawrey

525,659
79
751
1,130

2

@AlexMills it's worth noting that these researchers used a machine from 2006. A dual core i3-4370 might be 4-5x faster. Never the less their analysis is most likely current. – Peter Lawrey May 28 '15 at 05:21
maybe, but I assume only one core is responsible for loading the JVM. I bet a SSD vs HDD would make more difference. – Alexander Mills May 28 '15 at 05:22
1

@AlexMills it would if they ran the tests with a flushed cache. I suspect they ran the benchmark from memory but it is hard to say as they only had 1 GB of memory. – Peter Lawrey May 28 '15 at 05:27

score 1 · Answer 6 · answered May 09 '09 at 22:07

1

There are a number of reasons:

lots of jars to load
verification (making sure code doesn't do evil things)
JIT (just in time compilation) overhead

I'm not sure about the CLR, but I think it is often faster because it caches a native version of assemblies for next time (so it doesn't need to JIT). CPython starts faster because it is an interpreter, and IIRC, doesn't do JIT.

answered May 09 '09 at 22:07

Zifre

26,504
11
85
105

Classes compiled with -target 1.6 are much faster to verify (the Harmony verifier is also much faster). – Tom Hawtin - tackline May 10 '09 at 03:23
1

CPython compiles Python files into bytecode before executing them, like Java. – Bastien Léonard May 10 '09 at 07:44
@Bastien: there is a big difference between bytecode and machine code. Made up bytecode is *much* easier than generating machine code. – Zifre May 10 '09 at 13:13

score 1 · Answer 7 · answered May 10 '09 at 01:58

In addition to things already mentioned (loading classes, esp. from compressed JARs); running in interpreted mode before HotSpot compiles commonly-used bytecode; and HotSpot compilation overhead, there is also quite a bit of one-time initialization done by JDK classes themselves. Many optimizations are done in favor of longer-running systems where startup speed is less of a concern.

And as to unix style pipelining: you certainly do NOT want to start and re-start JVM multiple times. That is not going to be efficient. Rather chaining of tools should happen within JVM. This can not be easily intermixed with non-Java Unix tools, except by starting such tools from within JVM.

(3 years too late) It can, with a tool like Nailgun! – salezica Mar 18 '12 at 01:40 — salezica, Mar 18 '12 at 01:40

score -1 · Answer 8 · answered May 10 '09 at 07:39

All VMs with a rich type system such as Java or CLR will not be instanteous when compared to less rich systems such as those found in C or C++. This is largely because a lot is happening in the VM, a lot of classes get initialized and are required by a running system. Snapshots of an initialized system do help but it still costs to load that image back into memory etc.

A simple hello world styled one liner class with a main still requires a lot to be loaded and initialized. Verifying the class requires a lot of dependency checking and validation all which cost time and many CPU instructions to be executed. On the other hand a C program will not do any of these and will amount of a few instructions and then invoke the printer function.

Why is the JVM slow to start?

8 Answers8

Linked