Any way to boost JVM Startup Speed?

Question

It is said that Java is 10x faster than python in terms of performance. That\'s what I see from benchmarks too. But what really brings down Java is the JVM startup time.

Answer 1

Change your program to a client/server model, where the Java part is a persistent server that is started only once, fed by a client that tells it what to do. The client could be a small Python script telling the server process what files to consume. Maybe send commands via a socket, or signals, up to you.

Answer 2

Um... write the documents to a directory (if they're not already) and have the Java program process all of them in one go?

Answer 3

I refer you to Matthew Gilliard's (mjg) blog post on the topic. Any code examples below come straight from there. I won't include timing examples partly to keep this short and partly to induce you to visit his page. Matthew works on the Fn Project so he's very interested in figuring out how to keep startup times low.

Apparently there are a few ways to do it, and some are pretty easy as well. The core idea is that you cache the JVM's initialization cycle instead of executing it on every startup.

Class Data Sharing (CDS)

CDS caches the deterministic (hardware dependant) startup process of the JDK. It's the easiest and oldest (since 1.5 I believe) trick in the book (and not very well-known).

From Oracle

When the JVM starts, the shared archive is memory-mapped to allow sharing of read-only JVM metadata for these classes among multiple JVM processes. The startup time is reduced thus saving the cost because restoring the shared archive is faster than loading the classes.

You can create the dump manually by running

⇒ java -Xshare:dump
Allocated shared space: 50577408 bytes at 0x0000000800000000
Loading classes to share ...
// ...snip ...
total   :  17538717 [100.0% of total] out of  46272512 bytes [ 37.9% used]

...and then use it with

java -Xshare:on HelloJava

AOT: Ahead of Time Compilation (Java 9+)

From mjg's blog

Where CDS does some parts of classloading of core classes in advance, AOT actually compiles bytecode to native code (an ELF-format shared-object file) in advance, and can be applied to any bytecode.

Use SubstrateVM (Java 8+)

Not in the blog post but demonstrated during the talk he gave a few days ago.

From the readme:

Substrate VM is a framework that allows ahead-of-time (AOT) compilation of Java applications under closed-world assumption into executable images or shared objects (ELF-64 or 64-bit Mach-O).

Answer 4

Just learned about drip today, as an alternative replacement to nailgun: https://github.com/flatland/drip Also see this page for some general hints: see also https://github.com/jruby/jruby/wiki/Improving-startup-time

Answer 5

There are lots of ways to do this - basically anything will work providing it keeps the JVM alive for the duration of all of your batch processing.

e.g., why not just alter the Java program to loop through all the files and process them all in one invocation of the JVM?

Or you could build a simple GUI application in Swing and have some visual way to run the batch (e.g. select target directories, then press "Process All..." button).

Or you could use a Clojure REPL as a way to script the execution of the appropriate Java job....

Or you could create a server process with something like Netty and send all your files through that....

Answer 6

Try Nailgun.

Note: I don't use it personally.