Just-in-time compiling

Early JVMs always interpreted Java bytecodes. This had a large performance penalty of between a factor 10 and 20 for Java versus C in average applications.^[5] To combat this, a just-in-time (JIT) compiler was introduced into Java 1.1. Due to the high cost of compiling, an added system called HotSpot was introduced in Java 1.2 and was made the default in Java 1.3. Using this framework, the Java virtual machine continually analyses program performance for hot spots which are executed frequently or repeatedly. These are then targeted for optimizing, leading to high performance execution with a minimum of overhead for less performance-critical code.^[6][7] Some benchmarks show a 10-fold speed gain by this means.^[8] However, due to time constraints, the compiler cannot fully optimize the program, and thus the resulting program is slower than native code alternatives.^[9][10]

Adaptive optimizing

Adaptive optimizing is a method in computer science that performs dynamic recompilation of parts of a program based on the current execution profile. With a simple implementation, an adaptive optimizer may simply make a trade-off between just-in-time compiling and interpreting instructions. At another level, adaptive optimizing may exploit local data conditions to optimize away branches and use inline expansion.

A Java virtual machine like HotSpot can also deoptimize code formerly JITed. This allows performing aggressive (and potentially unsafe) optimizations, while still being able to later deoptimize the code and fall back to a safe path.^[11][12]

Garbage collection

The 1.0 and 1.1 Java virtual machines (JVMs) used a mark-sweep collector, which could fragment the heap after a garbage collection. Starting with Java 1.2, the JVMs changed to a generational collector, which has a much better defragmentation behaviour.^[13] Modern JVMs use a variety of methods that have further improved garbage collection performance.^[14]

Other optimizing methods

public String getNames() {
     final Vector<String> v = new Vector<>();
     v.add("Me");
     v.add("You");
     v.add("Her");
     return v.toString();
}

Java SE 6 Update 10

• Java Quick Starter reduces application start-up time by preloading part of JRE data at OS startup on disk cache.^[27]
• Parts of the platform needed to execute an application accessed from the web when JRE is not installed are now downloaded first. The full JRE is 12 MB, a typical Swing application only needs to download 4 MB to start. The remaining parts are then downloaded in the background.^[28]
• Graphics performance on Windows improved by extensively using Direct3D by default,^[29] and use shaders on graphics processing unit (GPU) to accelerate complex Java 2D operations.^[30]

Java 7

Several performance improvements have been released for Java 7: Future performance improvements are planned for an update of Java 6 or Java 7:^[31]

• Provide JVM support for dynamic programming languages, following the prototyping work currently done on the Da Vinci Machine (Multi Language Virtual Machine),^[32]
• Enhance the existing concurrency library by managing parallel computing on multi-core processors,^[33][34]
• Allow the JVM to use both the client and server JIT compilers in the same session with a method called tiered compiling:^[35]
  • The client would be used at startup (because it is good at startup and for small applications),
  • The server would be used for long-term running of the application (because it outperforms the client compiler for this).
• Replace the existing concurrent low-pause garbage collector (also called concurrent mark-sweep (CMS) collector) by a new collector called Garbage First (G1) to ensure consistent pauses over time.^[36][37]

Program speed

Benchmarks often measure performance for small numerically intensive programs. In some rare real-life programs, Java out-performs C. One example is the benchmark of Jake2 (a clone of Quake II written in Java by translating the original GPL C code). The Java 5.0 version performs better in some hardware configurations than its C counterpart.^[42] While it is not specified how the data was measured (for example if the original Quake II executable compiled in 1997 was used, which may be considered bad as current C compilers may achieve better optimizations for Quake), it notes how the same Java source code can have a huge speed boost just by updating the VM, something impossible to achieve with a 100% static approach.

For other programs, the C++ counterpart can, and usually does, run significantly faster than the Java equivalent. A benchmark performed by Google in 2011 showed a factor 10 between C++ and Java.^[43] At the other extreme, an academic benchmark performed in 2012 with a 3D modelling algorithm showed the Java 6 JVM being from 1.09 to 1.91 times slower than C++ under Windows.^[44]

Some optimizations that are possible in Java and similar languages may not be possible in certain circumstances in C++:^[45]

• C-style pointer use can hinder optimizing in languages that support pointers,
• The use of escape analysis methods is limited in C++, for example, because a C++ compiler does not always know if an object will be modified in a given block of code due to pointers,^{[note 1]}
• Java can access derived instance methods faster than C++ can access derived virtual methods due to C++'s extra virtual-table look-up. However, non-virtual methods in C++ do not suffer from v-table performance bottlenecks, and thus exhibit performance similar to Java.

The JVM is also able to perform processor specific optimizations or inline expansion. And, the ability to deoptimize code already compiled or inlined sometimes allows it to perform more aggressive optimizations than those performed by statically typed languages when external library functions are involved.^[46][47]

Results for microbenchmarks between Java and C++ highly depend on which operations are compared. For example, when comparing with Java 5.0:

• 32 and 64 bit arithmetic operations,^[48][49] File I/O^[50] and Exception handling,^[51] have a similar performance to comparable C++ programs
• Arrays^[52] operations performance are better in C.
• Trigonometric functions performance is much better in C.^[53]

Notes

Multi-core performance

The scalability and performance of Java applications on multi-core systems is limited by the object allocation rate. This effect is sometimes called an "allocation wall".^[54] However, in practice, modern garbage collector algorithms use multiple cores to perform garbage collection, which to some degree alleviates this problem. Some garbage collectors are reported to sustain allocation rates of over a gigabyte per second,^[55] and there exist Java-based systems that have no problems scaling to several hundreds of CPU cores and heaps sized several hundreds of GB.^[56]

Automatic memory management in Java allows for efficient use of lockless and immutable data structures that are extremely hard or sometimes impossible to implement without some kind of a garbage collection. Java offers a number of such high-level structures in its standard library in the java.util.concurrent package, while many languages historically used for high performance systems like C or C++ are still lacking them.

Startup time

Java startup time is often much slower than many languages, including C, C++, Perl or Python, because many classes (and first of all classes from the platform Class libraries) must be loaded before being used.

When compared against similar popular runtimes, for small programs running on a Windows machine, the startup time appears to be similar to Mono's and a little slower than .NET's.^[57]

It seems that much of the startup time is due to input-output (IO) bound operations rather than JVM initialization or class loading (the rt.jar class data file alone is 40 MB and the JVM must seek much data in this big file).^[27] Some tests showed that although the new split bytecode verification method improved class loading by roughly 40%, it only realized about 5% startup improvement for large programs.^[58]

Albeit a small improvement, it is more visible in small programs that perform a simple operation and then exit, because the Java platform data loading can represent many times the load of the actual program's operation.

Starting with Java SE 6 Update 10, the Sun JRE comes with a Quick Starter that preloads class data at OS startup to get data from the disk cache rather than from the disk.

Excelsior JET approaches the problem from the other side. Its Startup Optimizer reduces the amount of data that must be read from the disk on application startup, and makes the reads more sequential.

In November 2004, Nailgun, a "client, protocol, and server for running Java programs from the command line without incurring the JVM startup overhead" was publicly released.^[59] introducing for the first time an option for scripts to use a JVM as a daemon, for running one or more Java applications with no JVM startup overhead. The Nailgun daemon is insecure: "all programs are run with the same permissions as the server". Where multi-user security is needed, Nailgun is inappropriate without special precautions. Scripts where per-application JVM startup dominates resource use, see one to two order of magnitude runtime performance improvements.^[60]

Memory use

Java memory use is much higher than C++'s memory use because:

• There is an overhead of 8 bytes for each object and 12 bytes for each array^[61] in Java. If the size of an object is not a multiple of 8 bytes, it is rounded up to next multiple of 8. This means an object holding one byte field occupies 16 bytes and needs a 4-byte reference. C++ also allocates a pointer (usually 4 or 8 bytes) for every object which class directly or indirectly declares virtual functions.^[62]
• Lack of address arithmetic makes creating memory-efficient containers, such as tightly spaced structures and XOR linked lists, currently impossible (the OpenJDK Valhalla project aims to mitigate these issues, though it does not aim to introduce pointer arithmetic; this cannot be done in a garbage collected environment).
• Contrary to malloc and new, the average performance overhead of garbage collection asymptotically nears zero (more accurately, one CPU cycle) as the heap size increases.^[63]
• Parts of the Java Class Library must load before program execution (at least the classes used within a program).^[64] This leads to a significant memory overhead for small applications.
• Both the Java binary and native recompilations will typically be in memory.
• The virtual machine uses substantial memory.
• In Java, a composite object (class A which uses instances of B and C) is created using references to allocated instances of B and C. In C++ the memory and performance cost of these types of references can be avoided when the instance of B and/or C exists within A.

In most cases a C++ application will consume less memory than an equivalent Java application due to the large overhead of Java's virtual machine, class loading and automatic memory resizing. For programs in which memory is a critical factor for choosing between languages and runtime environments, a cost/benefit analysis is needed.

Trigonometric functions

Performance of trigonometric functions is bad compared to C, because Java has strict specifications for the results of mathematical operations, which may not correspond to the underlying hardware implementation.^[65] On the x87 floating point subset, Java since 1.4 does argument reduction for sin and cos in software,^[66] causing a big performance hit for values outside the range.^[67]

Java Native Interface

The Java Native Interface invokes a high overhead, making it costly to cross the boundary between code running on the JVM and native code.^[68][69][70] Java Native Access (JNA) provides Java programs easy access to native shared libraries (dynamic-link library (DLLs) on Windows) via Java code only, with no JNI or native code. This functionality is comparable to Windows' Platform/Invoke and Python's ctypes. Access is dynamic at runtime without code generation. But it has a cost, and JNA is usually slower than JNI.^[71]

User interface

Swing has been perceived as slower than native widget toolkits, because it delegates the rendering of widgets to the pure Java 2D API. However, benchmarks comparing the performance of Swing versus the Standard Widget Toolkit, which delegates the rendering to the native GUI libraries of the operating system, show no clear winner, and the results greatly depend on the context and the environments.^[72] Additionally, the newer JavaFX framework, intended to replace Swing, addresses many of Swing's inherent issues.

Use for high performance computing

Some people believe that Java performance for high performance computing (HPC) is similar to Fortran on compute-intensive benchmarks, but that JVMs still have scalability issues for performing intensive communication on a grid computing network.^[73]

However, high performance computing applications written in Java have won benchmark competitions. In 2008,^[74] and 2009,^[75][76] an Apache Hadoop (an open-source high performance computing project written in Java) based cluster was able to sort a terabyte and petabyte of integers the fastest. The hardware setup of the competing systems was not fixed, however.^[77][78]

In programming contests

Programs in Java start slower than those in other compiled languages.^[79][80] Thus, some online judge systems, notably those hosted by Chinese universities, use longer time limits for Java programs^{[81][82][83][84][85]} to be fair to contestants using Java.