- 60 - HotSpot has the more leisurely startup time acceptable for long-running server processes. In the
future you can expect to see VMs differentiated by their startup times even more.
Finally, the application architecture and class file configuration determine the last component of startup time. The application may require many classes and extensive initializations before the
application is started, or it may be designed to start up as quickly as possible. It is useful to bear in mind the user perception of application startup when designing the application. For example, if you
can create the startup window as quickly as possible and then run any initializations in the background without blocking windowing activity, the user will see this as a faster startup than if
you waited for initializations to finish before creating the initial window. This design takes more work, but improves startup time.
The number of classes that need to be loaded before the application starts are part of the application initializations, and again the application design affects this time. In the later section
Section 3.8 , I
discuss the effects of class file configuration on startup time. Section 13.3
, also has an example of designing an application to minimize startup time.
3.3.4 Other VM Optimizations
On the VM side, improvements are possible using JIT compilers to compile methods to machine code, using algorithms for code caching , applying intelligent analyses of runtime code, etc. Some
bytecodes allow the system to bypass table lookups that would otherwise need to be executed. But these bytecodes take extra effort to apply to the VM. Using these techniques, an intelligent VM
could skip some runtime steps after parts of the application have been resolved.
Generally, a VM with a JIT compiler gives a huge boost to a Java application, and is probably the quickest and simplest way to improve performance. The most optimistic predictions are that using
optimizing compilers to generate bytecodes, together with VMs with intelligent JIT recompilers, will put Java performance on a par with or even better than an equivalent natively compiled C++
application. Theoretically, better performance is possible. Having a runtime environment adapt to the running characteristics of a program should, in theory at least, provide better performance than a
statically compiled application. A similar argument runs in CPU design circles where dynamic rescheduling of instructions to take account of pipelining allows CPUs to process instructions out of
order. But at the time of writing this book, we are not particularly close to proving this theory for the average Java application. The time available for a VM to do something other than the most basic
execution and bytecode translation is limited. The following quote about dynamic scheduling in CPUs also applies to adaptive VMs:
At runtime, the CPU knows almost everything, but it knows everything almost too late to do anything about it. Tom R. Halfhill quoting Gerrit A. Slavenburg, Inside IA-64, Byte, June 1998
As an example of an intelligent VM, Suns HotSpot VM is targeted precisely to this area of adaptive optimization. This VM includes some basic improvements all of which are also present in
VMs from other vendors such as using direct pointers instead of Java handles
[3]
which may be a security issue, improved thread synchronization, a generational garbage collector, speedups to
object allocation, and an improved startup time by not JIT-compiling methods initially. In addition to these basic improvements, HotSpot includes adaptive optimization, which works as follows:
HotSpot runs the application initially in interpreted mode as if there is no JIT compiler present while a profiler identifies the bottlenecks in the application. Then, an optimizing JIT compiler
compiles into native machine code only those hotspots in the application that are causing the bottlenecks. Because only a small part of the application is targeted, the JIT compiler which might
in this case be more realistically called an after-a-while compiler rather than a just-in-time
- 61 - compiler can spend extra time compiling those targeted parts of the application, thus allowing
more than the most basic compiler optimizations to be applied.
[3]
A handle is a pointer to a pointer. Java uses handles to ensure security, so that one object cannot gain direct access to another object without the security capabilities of Java being able to intervene.
Consider the example where 20 of the code accounts for 80 of the running application time. Here, a classic JIT compiler might improve the whole application by 30: the application would now take 70
of the time it originally took.
The HotSpot compiler ignores the nonbottlenecked code, instead focusing on getting the 20 of hotspot code to run twice as fast. The 80 of application time is halved to just 40 of the original time. Adding
in the remaining 20 of time means that the application now runs in 60 of the original time. These percentage figures are purely for illustration purposes.
Note, however, that HotSpot can try too hard sometimes. For example, HotSpot can speculatively optimize on the basis of guessing the type of particular objects. If that guess turns out to be wrong,
HotSpot has to deoptimize the code, which results in some very variable timings.
So far, I have no evidence that optimizations I have applied in the past and detailed in this book have caused any problems after upgrading compilers and VMs. However, it is important to note that
the performance characteristics of your application may change with different VMs and compilers, and not necessarily always for the better. Be on the lookout for any problems a new compiler and
VM may bring, as well as the advantages. The technique of loading classes explicitly from a new thread after application startup can conflict with a particular JIT VMs caching mechanism and
actually slow down the startup sequence of your application. I have no evidence for this; I am just speculating on possible conflicts.
3.4 Better Optimizing Compilers
