[Table of Contents/Page 1] [Page 2] [Page 3] [Page 4] [Page 5]
Table of Contents
- Introduction and Overview
- The Java HotSpot VM Architecture
- Debugging Support
- The Java HotSpot Compilers
- Impact on Software Reusability
- Summary
- Availability
Back to Top
1. Introduction and Overview
Java HotSpot technology delivers higher performance and more reliability over previous versions. Both client and server versions feature a number of improvements which enable developers to create more demanding applications in less time. It provides the foundation for the Java 2 Platform, Standard Edition (J2SE) version 1.4 software, the premier solution for rapidly developing and deploying business-critical enterprise applications. It is available for Microsoft Windows, Linux, and Solaris Operating Environment (OE), as well as for other platforms through Java technology licensees.
The Java HotSpot Virtual Machine is the foundation for Java 2 Platform, Standard Edition technology.
|
The Java 2 Platform has become a mainstream vehicle for software development and deployment. With millions of developers and users, the Java platform is growing explosively in many dimensions: from credit cards to wireless devices to desktops to mainframes. It is the underlying foundation for deploying Web page applets, Web services, large commercial applications, and more.
This latest version of the Java HotSpot virtual machine (VM) builds upon Java technology's cross-platform support and robust security model with new features and capabilities for scalability, quality, and performance. In addition to new features, this latest version of the Java HotSpot VM is upward compatible with previous releases.
The Java HotSpot VM supports virtually all aspects of development, deployment, and management of corporate applications, and is used by:
Integrated development environments (IDE) including Sun ONE Developer Studio, Borland JBuilder, WebGain Visual Cafe, Oracle JDeveloper, Metrowerks CodeWarrior, and the NetBeans open-source project.
-
Application server vendors, such as the Sun ONE Application Server and BEA Systems WebLogic software.
Sun Microsystems, Inc. is also driving performance improvements through the use of various industry standard and internally developed benchmarks. These improvements are applicable to both the client-side and server-side JVM environments.
The Java 2 SDK, Standard Edition, contains two implementations of the Java virtual machine (VM):
-
Java HotSpot Client VM, which is the default virtual machine of the Java 2 SDK and Java 2 Runtime Environment. It is tuned for best performance when running applications in a client environment by reducing application start-up time and memory footprint.
-
Java HotSpot Server VM, which is designed for maximum program execution speed for applications running in a server environment.
Solid Foundation
This version of the Java HotSpot VM builds on a strong foundation of features and capabilities. The previous version incorporated the following capabilities:
- Runtime
- Ultra-fast thread synchronization, resulting in maximum performance of thread-safe Java technology-based programs.
- Better fatal error reporting: When a fatal error occurs in the virtual machine, there was improved output, including a mechanism to detect if the crash was in the VM itself, or whether the crash was caused by user-supplied native code external to the VM.
- Improved support for debugging and profiling: Many features of the Java Virtual Machine Debugger Interface (JVMDI) were supported. In addition, there was an experimental interface-Java Virtual Machine Profiler Interface (JVMPI). Note that the JVMPI is being deprecated in version 1.4 and later releases.
- Garbage Collection: The garbage collector (GC) was made fast and fully accurate, and more reliably collected unused or free objects. Use of state-of-the-art algorithms dramatically reduced or eliminated user-perceivable garbage-collection pauses. The GC was enhanced to include:
- Larger heaps: Garbage collectors were changed so that they could use the complete address space available in a 32-bit system. This provided access up to 4 GB heaps in the Solaris OE.
- Better soft reference policy: The policy for soft reference pointers was been modified to model the behavior of the Classic VM.
- The garbage collectors were tuned to support large applications and the SPARC 3 platform.
- Compiler Optimizations
- Range check elimination: The Java programming language specification requires array bounds checking to be performed with each array access. An index bounds check can be eliminated when the compiler can prove that an index used for an array access is within bounds.
- Loop unrolling: The Server VM featured loop unrolling, a standard compiler optimization that enables faster loop execution. Loop unrolling increases the loop body size while simultaneously decreasing the number of iterations. Loop unrolling also increases the effectiveness of other optimizations.
- Instruction scheduling: Machine instructions generated by the compiler's code generator do not necessarily appear in optimal order for a particular hardware platform. Instruction scheduling is a compiler optimization that rearranges the generated machine instructions such that the execution speed is improved. This was a SPARC 3-specific optimization.
- Object-oriented optimizations for the Java reflection API: The compiler was aware of important library functions, which resulted in better performance when generating code for them.
Back to Top
New in this Release
The Java HotSpot VM v1.4.0 release contains many improvements in scalability, performance, reliability, and serviceability (RAS) over previous versions. Overall performance is significantly enhanced by using a variety of techniques, including improved garbage collection, thread handling, and others. As well, the on-the-fly adaptive optimization technology which detects and accelerates performance-critical code has been further refined and tuned.
The main areas of improvement are:
Scalability
- 64-bit support on Solaris-SPARC Platform Edition: 64-bit support provides Java technology developers with near limitless amounts of memory for high-performance, high-scalability computing. While previous J2SE releases were limited to addressing 4 gigabytes of RAM, version 1.4 allows Java technology applications to access hundreds of gigabytes of RAM. This enables developers to drive more applications and very large datasets into memory, and avoids the performance overhead of reading data in from a disk or from a database. The result is significantly faster processing for business intelligence, data mining, engineering and scientific applications. Developers can take advantage of the benefits of 64-bit computing without rewriting their existing Java applications. Note that 64-bit functionality is available only on Java HotSpot Server Compiler environments, and on the Solaris OE.
Performance
Improved Debugging: The full performance advantage of the Java HotSpot virtual machine is available to client VM programs running while in debugging mode with Full Speed Debugging . This allows testing to proceed at full speed and allows longer running programs to be more easily debugged. Faster Reflection: The JVM now generates bytecode stubs for frequently used reflective objects such as Methods, Constructors, and Classes. This provides significant speedup in reflection-intensive code, such as used in serialization. The improvements are visible when running RMI, JINI, or CORBA code environments. Object Serialization: The JVM has also sped up code paths in object serialization, specifically in accessing and setting fields, method invocation, and internal synchronization overhead. As with the reflection improvements, this is visible when running RMI, JINI, or CORBA code environments. New I/O (NIO): The NIO APIs introduced in version 1.4 provide new features and improved performance in the areas of buffer management, scalable network and file I/O, character-set support, and regular-expression matching. For example, there is no longer a requirement for one thread per network connection. Reducing thread overhead enables more network connections. The NIO APIs supplement the I/O facilities in the java.io package. NIO in version 1.4 is a subset of the changes proposedin JSR 51. Other NIO-related improvements include:
The NIO-related entry points allow native code to access java.nio direct buffers. The contents of a direct buffer can, potentially, reside in native memory outside of the ordinary garbage-collected heap. This allows memory-mapped data to be shared across the Java-native boundary, resulting in dramatic performance improvements for certain operations. A new invocation interface routine, AttachCurrentThreadAsDaemon, allows native code to attach a daemon thread to the VM. This is useful when the VM should not wait for this thread to exit upon shutdown.
Garbage collection policy: In addition to providing support for the large heaps enabled with a 64-bit address space, there have been several subtle improvements. One of the most important is in the area of generation sizing. J2SE version 1.4 provides improved heuristics for selecting the most efficient settings which can have dramatic effects on GC throughput. Note that the fundamental GC algorithms used by the Java HotSpot VM have not changed significantly since J2SE 1.3.1.
Back to Top
Reliability, Availability, Serviceability (RAS)
A new command-line option for performing additional Java Native Interface (JNI) checks is available. The -Xcheck:jni command-line option performs additional checks for Java Native Interface (JNI) functions. This enables checks for argument validity to be run during development, where they can be detected before they are deployed and slow down production runs. Specifically, the Java HotSpot VM validates the parameters passed to the JNI function as well as the runtime environment data before processing the JNI request. Any invalid data encountered indicates a problem in the native code, and the VM will terminate with a fatal error in such cases. Java Platform Debugger Architecture (JPDA) Enhancements: JPDA is a multi-tiered debugging architecture that allows tools developers to easily create debugger applications which run portably across platforms, virtual machine (VM) implementations and SDK versions. Enhancements related to version 1.4 include:
Full Speed Debugging: The VM now uses "full-speed debugging." In the previous version of the Java HotSpot VM, when debugging was enabled the program executed using only the interpreter. Now, the full performance advantage of HotSpot compiler technology is available to client VM programs running with debugging enabled. The improved performance enables long running programs to be more easily debugged. As well, testing can proceed at full speed and the launch of a debugger can occur on an exception. "HotSwap" Class File Replacement: This new feature provides the ability to substitute modified code in a running application through the debugger APIs. HotSwap adds functionality to the JPDA, enabling a class to be updated while under the control of a debugger. For example, one can recompile a single class and replace the old instance with the new instance. This feature has two main benefits. First, once a developer has identified a problem in the debugger, they can fix it and continue debugging. Second, organizations deploying long running servers can fix bugs without taking down the server. Support For Debugging Other Languages: The JPDA has been extended so that non Java programming language source, which is translated into Java programming language source or Java virtual machine class file format can be debugged at the original non Java programming language source code level.
Error-reporting mechanism: When the VM detects a crash in native code such as JNI code written by the developer or when the JVM itself crashes, it will printand log debug information about the crash. This error message normally will include information such as the function name, library name, source-file name and line number at which the error occurred. This enables developers to more easily and efficiently debug their applications. If an error message indicates a problem in the JVM code itself, it will allow a developer to submit a more accurate and helpful bug report. Solaris threading scalability improvements: Java can now take advantage of the new thread model available for the Solaris 8 and Solaris 9 OE. The thread model maps light-weight processes (LWPs) one-to-one to Solaris kernel threads. This model improves stability, decreases thread starvation, provides more balanced thread scheduling, improves system-level synchronization and overall scalability.
In a benchmark launching worker threads equal to the number of CPUs, all the threads perform nearly equal amounts of operations (within 5%), whereas with J2SE 1.3 the spread between threads doing the most and least operations could exceed 20%. This improves CPU utilization on multi-CPU systems using version 1.4. Signal-chaining facility: Signal-chaining enables the Java Platform to better interoperate with native code that installs its own signal handlers. The facility works on both Solaris and Linux platforms. The signal-chaining facility was introduced to remedy a problem with signal handling in previous versions of the Java HotSpot VM. Prior to version 1.4, the Java HotSpot VM would not allow application-installed signal handlers for certain signals including, for example, SIGBUS, SIGSEGV, SIGILL, etc., since those signal handlers could conflict with the signal handlers used internally by the Java HotSpot VM.
Back to Top
[Table of Contents/Page 1] [Page 2] [Page 3] [Page 4] [Page 5]
|
|
Print-friendly Version
