来源：

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

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.

Copyright © 1999 Sun Microsystems, Inc. All Rights Reserved.

Java Software