JVMPerformance

[PageOutline]

JVM Arguments and Performance

Because the Open Trip Planner components are written in Java, they are all executed on Java virtual machines (JVM). The web application (and the Tomcat server it runs on), the graph builder, perhaps even your development environment (Eclipse) may each need a slightly different virtual machine setup to run best. For example, because the trip planner and graph builder are usually dealing with very large data sets, the default maximum amount of working memory Java sets aside (64MiB) is rarely enough.

A typical set of JVM arguments, say for a graph builder run configuration, might be:

-Xmx1500m -d32 -server

This sets the maximum memory allocation pool size to 1.5 GiB, specifies a 32-bit data model, and forces the optimizing "server" JVM instead of the potentially slower "client" one.

Memory allocation pool size

According to the java manual page, the -Xmx argument "Specifies the maximum size, in bytes, of the memory allocation pool... Append the letter k or K to indicate kilobytes, the letter m or M to indicate megabytes, the letter g or G to indicate gigabytes, or the letter t or T to indicate terabytes."

If you are using a 64-bit data model (see following section) the amount of memory you let Java use is practically unlimited; however it is unwise to go over the amount of free physical memory on your machine. If you use a 32-bit data model on OS X, Linux, and non-SPARC Solaris the maximum allocation pool size is around 2000m minus some overhead. Some platforms may allow closer to the full 4GiB of memory theoretically addressable with 32 bits. If you need more space than this, you will need to switch to a 64 bit data model. This has the unfortunate side effect of increasing memory usage itself.

NOTE: Newer 64-bit JVMs have CompressedOops (compressed object pointers) turned on by default, as long as the heap is less than 32GB in size. On these JVMs the difference in memory consumption will be much less apparent. See: https://wikis.oracle.com/display/HotSpotInternals/CompressedOops

Data Model

Without getting into the details (better covered elsewhere on the web), a 32-bit model will consume less memory than a 64-bit model for the same task, but is incapable of making use of more than 4GiB of memory. In practice, this limit is often much lower, around 1.6GiB (see above). If your graph builder run, server, etc. does not fit in about 1.5GiB of memory, you will probably need to use a 64-bit model.

Graph building uses more memory than merely running, and the graph format is independent of the data model. This means that you might be able to build your graph on a big machine using a 64-bit model, and run on a smaller machine with a 32-bit model.

Client / Server JVM

The most common current JVMs (Hotspot) do what's called just-in-time (JIT) compilation, using one of two strategies. The "client" JVM does less optimisation but starts up faster, and the "server" JVM will highly optimize the code, watching during execution for clues on how to speed things up. The server JVM requires a warmup period while it optimizes execution, but is a much better choice for computation-oriented software like OTP. It can double the speed of path searches and CPU-intensive graph building operations like contraction. If you are running on a "server class" machine (2+ processor cores and 2+ GiB of RAM) Java should detect this automatically and use the server JVM, but on some platforms it will default to the client JVM. Specifying the -server argument will ensure that you don't needlessly compromise performance.

See definitions JIT, C1, and C2 on this page:

http://openjdk.java.net/groups/hotspot/docs/HotSpotGlossary.html

Profiling

If you want to observe OTP's memory and processor use in detail, you may find the VisualVM tool interesting, as well as its VisualGC plugin.