The Java HotSpotTM Server VM

最新推荐文章于 2024-08-13 15:08:43 发布

hertz2007

最新推荐文章于 2024-08-13 15:08:43 发布

阅读量877

点赞数

分类专栏： Java 文章标签： java server compilation compiler performance security

Java 专栏收录该内容

5 篇文章 0 订阅

订阅专栏

来源：

http://java.sun.com/products/hotspot/docs/general/hs2.html

The Java HotSpot^TM Server VM

The Solution for Reliable, Secure Performance for the Enterprise

Documentation Contents

The Java HotSpot^TM Server VM is Sun Microsystem's solution for providing fast, reliable Java^TM technology in the enterprise server environment. Most reviews and analyses of Java HotSpot technology have focused on its world-class speed. This is understandable; the Java HotSpot Server VM was the world's fastest virtual machine implementation when it was launched (with the product name "Java HotSpot Performance Engine") in April 1999, and performance tuning has increased its speed by well over 30% since then. However, this document highlights a different, though equally important, aspect of Java HotSpot technology -- its reliability, robustness, and security.

Security

The Java HotSpot Server VM is the most secure solution for Java technology on the server. In fact, the Java HotSpot Server VM is fully as secure as a straight interpreter, even while adaptively compiling and de-compiling code on the fly. The Java HotSpot Server VM also supports the entire suite of security enhancements that are part of the new Java 2 Platform.

Secure as an Interpreter

Security on the Java platform is based on protection domains. When the Java platform calls a method to perform a security-sensitive operation, it typically happens that the method invocation sets off a series of calls to methods in different classes before the desired operation is actually performed. In such cases, the security mechanism must ensure that each class on the call stack meets the security requirements of the operation that is finally performed.

The Java HotSpot Server VM is as fully secure as a straight interpreter, even while adaptively compiling and decompiling code on the fly.

Checking the protection domains on the call stack presents no problem for interpreted code. For interpreted code, the stack is a true source-level call stack that exactly represents the structure of the bytecodes being executed. When compiling and inlining code, however, the information in the stack can become scrambled. Once compiled code from one method has been inlined into another method's code in a second class, the first class no longer appears on the call stack, and its protection domain cannot be checked by the platform's security mechanism. This presents a real obstacle for JIT and static compilers, and forces them to be very conservative in their inlining so they don't compromise security.

The Java HotSpot Server VM surmounts this problem by using, in effect, two call stacks. One stack reflects the fully optimized state of the dynamically compiled code, and HotSpot uses this stack for running the program. HotSpot also constructs on demand a second, ``virtual'' stack that retains the source-level call structure of the original bytecode. By referring to the virtual stack as necessary, the Java HotSpot Server VM can achieve the security of an interpreter while retaining the full performance benefits of its optimizing compiler.

Support for Java 2 Platform Security Enhancements

The Java HotSpot Server VM supports the Java 2 Platform, including the Java 2 Platform's security enhancements. The new security features include:

Policy-based, easily-configurable, fine-grained access control

When code is loaded, it is assigned permissions based on the security policy currently in effect. Each permission specifies a permitted access to a particular resource (such as "read" and "write" access to a specified file or directory, "connect" access to a given host and port, etc.). The policy, specifying which permissions are available for code from various signers/locations, can be initialized from an external configurable policy file. Unless a permission is explicitly granted to code, it cannot access the resource that is guarded by that permission.

The permissions and policy-based security of the Java 2 Platform is fully supported by the Java HotSpot Server VM.

Certificate interfaces and electronic signing

The Java HotSpot Server VM also supports the new certificate interfaces for parsing and managing electronically signed certificates.

Robustness

The Java HotSpot Server VM has many features that make it a more robust solution for enterprise computing than either JIT compilers or static compilation solutions.

Debugging

The Java HotSpot Server VM's virtual call stack gives it a big advantage in debugging as well as security. HotSpot can generate a debugging stack trace from the virtual stack when a program bug is encountered. Because the source-level virtual stack represents the true structure of a program, the stack traces produced from it yield unambiguous information about the location of potential problem spots in the code.

Without access to such a source-level call stack, traces produced by JIT compilers and VMs running statically compiled code are much more difficult to interpret.

The debugging problems are compounded in the case of static compilers because the code being executed is actually compiled C code rather than compiled bytecode, adding an additional layer of indirection and translation between the stack trace and the program's original Java source code.

Code Size

The Java HotSpot Server VM compiles only those parts of an application that are performance bottlenecks. Typically this will involve only a small part of the program, perhaps as little as 10% of the bytecode. Because only a relatively small amount of code is compiled, the Java HotSpot Server VM keeps runtime code size as small as possible while delivering the performance of large, fully optimized code.

Portability

The dynamic compiler in the Java HotSpot Server VM is highly portable, relying on a relatively small machine description file to describe all aspects of the target hardware. The portability of the compiler is attested by the fact that both implementations released by Sun (one for Win32 platforms and one for Solaris^TM SPARC^TM platforms) have posted best SPEC JVM 98 results for their respective hardwares.

The Java HotSpot Server VM has an additional dimension of portability not available to statically compiled code in that HotSpot takes bytecodes as input. This gives HotSpot the flexibility of an interpreter with the performance benefits of compiled code. The Java HotSpot Server VM can run bytecodes loaded remotely, make use of optional packages (formerly known as standard extensions), and can take advantage of introspection and reflection, all with fully optimized performance.

Garbage Collection

The Java HotSpot Server VM's garbage collector is fully accurate, unlike the conservative garbage collectors on most other Java runtime systems. Because the Java HotSpot collector is fully accurate, it can make several strong design guarantees that a conservative collector cannot make:

All inaccessible object memory can be reclaimed reliably.
All objects can be relocated, allowing object memory compaction, which eliminates object memory fragmentation and increases memory locality.

The Java HotSpot garbage collector is also fully incremental, eliminating user-detectable garbage-collection pauses. The incremental collector scales smoothly, providing non-distruptive, relatively constant pause times even when extremely large object data sets are being manipulated. This provides excellent behavior for:

Server applications, especially high-availability applications
Applications that manipulate very large ``live'' object data sets
Applications where all user-noticeable pauses are undesirable, such as highly interactive applications.

Systems that run statically compiled code will be hard pressed to match the benefits of the Java HotSpot garbage collector for long-running enterprise applications: no memory leaks, no heap fragmentation.

Systems that run statically compiled code will be hard pressed to match the benefits of the Java HotSpot garbage collector for long-running applications: no memory leaks, no heap fragmentation.

Dynamic Compilation

Straight bytecode interpretation is too slow for most enterprise applications. Any viable solution for performance on the enterprise needs to include compilation of the bytecodes to platform-specific native code to achieve reasonable program execution speed. Several strategies have been developed for addressing this need. The strategies can be categorized broadly by whether the compilation to native code takes place before runtime (static compilation) or during runtime (dynamic compilation) as with the Java HotSpot Server VM. Dynamic compilation has emerged as the clear winner over static compilation for performance.

Dynamic compilation has emerged as the clear winner over static compilation for performance.

The Java HotSpot Dynamic Compiler

The Java HotSpot Server VM starts a program by interpreting the bytecodes. As the program runs, a profiler monitors the program to determine the most heavily used portions of the code.

Nearly all applications spend most of their time in only a small portion of their code. The Java HotSpot profiler identifies those parts of an application's code that are most critical for performance. Java HotSpot then compiles and optimizes the performance-critical ``hot spots'' without wasting time compiling seldom-used code. Furthermore, the runtime analyses also enable the compiler to perform native-code optimizations not possible with static compilers.

Static Compilers

In contrast to dynamic compilers, static compilers translate bytecode into native code before runtime. For example, it is possible to first convert bytecodes into C source code, which is then compiled into platform-specific native code, as illustrated schematically in the following figure.

Optimization

The Java HotSpot Server VM's runtime analyses allow it to perform optimizations during compilation that are impossible with static compilers. For example, the HotSpot profiler can determine actual runtime sizes of arrays and vectors, identify program hot spots, and provide up-to-date information about what objects the program is creating and what classes have been loaded. The dynamic compiler can generate code that is tailor-made for the specific behavior of the program. One important optimization that dynamic compilation enables is aggresive method inlining.

Method Inlining

Method inlining is an important compiler optimization. However, static compilers are restricted in the amount of inlining they can do, for a couple of reasons. First, a static compiler can inline a method only if the compiler can determine that method is not overridden in a subclass. A static compiler can inline static, final, and private methods because it knows those methods can't be overridden. However, public and protected methods can be overridden in a subclass, and static compilers therefore cannot inline those methods.

Second, even if it were possible to determine through static analysis which methods are overridden and which are not, a static compiler still could not inline public methods. The Java language allows for loading of classes during runtime, and such dynamically loaded classes can change the structure of a program significantly. In particular, such dynamic loading can render invalid any inlining that was done based on pre-runtime, static analyses.

The Java HotSpot dynamic compiler uses runtime analysis to perform inlining aggressively, yet safely. Once the Java HotSpot profiler has collected runtime information about program hot spots, it not only compiles the hot spot into native code, but performs extensive method inlining on that code. The Java HotSpot compiler can afford to be aggressive in the way it inlines because it can always back out an inlining optimization if it determines that the method inheritance structure has changed during runtime due to dynamic class loading.

The Java HotSpot Server VM can revert to using the interpreter whenever compiler deoptimizations are called for because of dynamic class loading. When a class is loaded dynamically, HotSpot checks to ensure that the inter-class dependecies of inlined methods have not been altered. If any dependencies are affected by dynamically loaded class, HotSpot can back out affected inlined code, revert to interpreting for a while, and re-optimize later based on the new class dependencies.

When running statically compiled code, on the other hand, a virtual machine does not have access to the original bytecodes, and cannot fall back on an interpreter when optimizations in the statically compiled code become unsafe. Therefore, static compilers cannot be as aggressive in their optimization as dynamic compilers, and a performance penalty is the result.

The extensive inlining enabled by the Java HotSpot dynamic compiler gives it a huge advantage over static compilers. Inlining reduces the number of method invocations and their associated performance overhead. This is a significant bonus with the Java programming language in which methods are virtual by default and method invocations are frequent.

The extensive inlining enabled by the Java HotSpot dynamic compiler gives it a huge advantage over static compilers.

Furthermore, method inlining is synergistic with other optimizations. Inlining produces large blocks of code which make additional optimizations easier for the compiler to perform. The ability of the Java HotSpot Server VM to do aggressive inlining is a key factor in making HotSpot faster than current JIT and static compilers.

Summary -- Secure and Robust As Well As Fast

Java HotSpot technology enables high-performance, optimized code to be as secure as interpreted code. Moreover, the same technology adds robustness to the runtime environment by reducing runtime code size, eliminating memory leaks, reducing heap fragmentation, and enabling pauseless garbage collection.

The Java HotSpot Server VM takes bytecodes as input, allowing for easier code debugging, dynamic de-optimization at runtime, and the flexibility to run dynamically loaded bytecodes with optimized performance.

What's more, the Java HotSpot Server VM supports all features of the latest version of the Java 2 Platform, including the new security enhancements.

In short, the Java HotSpot Server VM is the best solution for providing fast, reliable Java technology for the enterprise.