HotSpot getting much warmer
|
The compilerHotSpot also has a full-fledged highly optimizing compiler built into it. Unlike a JIT compiler, HotSpot doesn't compile the entire program before running it, because doing so often incurs a large delay in running the program. HotSpot immediately begins running the program in interpreted mode. While it runs the program, it collects profiling information to find out where the program is spending time. HotSpot picks out the most commonly used parts of the program early in the life of the program (the 'hot spots') and then aggressively optimizes those parts. This technique tends to be effective because most programs spend the majority of their time executing a small fraction of the code.One of the most effective optimization techniques that HotSpot employs is called method inlining. Method inlining is removing a call to a method, replacing it with a suitably modified copy of the method body. Inlining generally results in a performance improvement, because a call to a non-final, non-static method is an expensive operation in Java.
While inlining is a common form of optimization in languages such as C and C++, it has traditionally been a lot harder to perform in highly dynamic languages such as Java. For HotSpot to be able to inline a method call, it has to be sure that it knows which implementation of the method will be called at runtime. Dynamic loading makes this job much harder, because inlining may need to be undone. The same sorts of problems crop up with other optimizations performed by HotSpot. Fortunately, HotSpot is able to get around these problems, as it contains facilities to deoptimize compiled code on the fly.
PerformanceOn the whole, HotSpot's features are likely to result in performance increases over traditional VMs. But how much of a performance increase will HotSpot offer?The answer is yet to be determined, as Sun has not yet released any benchmark information. Several people have written about HotSpot, claiming it is faster than natively compiled C or C++ because it expends a whole lot of effort fine tuning the most performance-critical parts of a program. We are skeptical of these claims, because a highly optimizing compiler can perform all of the same optimizations HotSpot would perform, but it would apply them uniformly across the entire program (though this would generally be done at the expense of potentially significant compilation time). In addition, HotSpot has the overhead of running an interpreter in the general case, and may also incur significant overhead associated with some of Java's dynamic behavior, such as automatic bounds checking and frequent dynamic casts. However, we certainly would be thrilled if we should turn out to be wrong. We'll have to wait for objective benchmark results to see. Another issue with HotSpot performance is that profiling and dynamic optimization both require the expenditure of resources that can potentially outweigh the benefits associated with them. For example, aggressive inlining generally ends up increasing code size dramatically. An increase of code size can lead to many page faults due to bad locality, which can end up undoing the effects of inlining or even slowing things down. We do believe that in most cases HotSpot will only result in faster code running. However, the verdict will be out until HotSpot has seen wide use.
Other issuesHotSpot is still a young, untested technology. For those who value robustness over efficiency, enter these waters slowly, as it is unclear what will be lurking in the depths. In fact, there is certainly cause for concern, since HotSpot is a far cry from the well-explored waters traditional VMs inhabit. It is not unreasonable to think that HotSpot will have implications that will not be well understood until it sees massive use. For example, security holes in the original implementation of the Java VM were still surfacing long after the first non-beta release of the software. It is possible that some of the optimizations being performed will have an unforeseen impact on security.
In fact, we have heard that one problem with HotSpot that partially contributed to its long delay was a bad interaction with Java 2's security mechanisms. Java 2 performs "stack inspection," where every called method has an associated privilege, and those privileges are checked throughout the stack when certain security-critical events occur. Apparently, HotSpot's inlining could cause a non-privileged method to be removed from the stack and inlined into a privileged method, which could lead to an operation that should have failed, due to insufficient privilege, actually being performed. HotSpot addresses this issue by using deoptimization information when performing stack inspections; however, such a fix requires changes to the security system, which has hardly withstood the test of time itself. Suffice it to say, HotSpot is an incredibly complex system, and it is reasonable to expect that unforeseen negative issues will manifest themselves gradually as the system moves into the marketplace.
AvailabilityAs mentioned above, HotSpot is currently in beta testing. Reports from Sun indicate that beta testers are generally impressed with its performance.After many months of delays, it currently looks like HotSpot will see widespread release in April. Unfortunately, HotSpot will not be a free product. Sun has yet to make any pricing information public. However, it seems that Sun will be targeting the enterprise server market, making it unlikely that HotSpot will see widespread adoption in the short term.
Resources
About the authorsJohn Viega is a research associate at Reliable Software Technologies, in Sterling, Va. He holds an M.S. in Computer Science from the University of Virginia. He developed and maintains Mailman, the Gnu mailing list manager. His research interests include software assurance, programming languages, and object-oriented systems.Tom O'Connor is a software engineer in the research division at Reliable Software Technologies. His interests are computer security and object-oriented software development.
Modified March 12, 1999.
Networking Solutions
|
