The Java HotSpot Virtual Machine, v1.4.1

Print-friendly Version

[Table of Contents/Page 1]  [Page 2]  [Page 3]  [Page 4]  [Page 5]  

Table of Contents

1. Introduction and Overview
• New in Java HotSpot Virtual Machine Release 1.4.1
• Java HotSpot VM -- Built on a Solid Foundation
• Scalability
• Performance
• Reliability, Availability, Serviceability (RAS)
• Earlier Enhancements
2. The Java HotSpot VM Architecture
• Overview
• Memory Model
• Garbage Collection
• 64-bit Architecture
• Ultra-Fast Thread Synchronization
• New I/O APIs
3. Debugging Support
• Overview
• Java Virtual Machine Debugger Interface (JVMDI)
• Java Debug Wire Protocol (JDWP)
• Java Debug Interface (JDI)
• Full Speed Debugging
• HotSwap Class File Replacement
• VMDeathRequests
• Logging
4. The Java HotSpot Compilers
• Overview
• Hot Spot Detection
• Method Inlining
• Dynamic Deoptimization
• Java HotSpot Client Compiler
• Java HotSpot Server Compiler
5. Impact on Software Reusability
6. Overview
7. Summary
8. Availability
9. Resources

Back to Top

Java HotSpot technology delivers higher performance and greater reliability over previous versions. Both client and server versions feature a number of improvements that enable developers to create more demanding applications in less time. Java HotSpot technology provides the foundation for the Java 2 Platform,Standard Edition (J2SE ) version 1.4.1 software,the premier solution for rapidly developing and deploying business-critical enterprise applications. J2SE technology is available for Microsoft Windows, Linux, and the Solaris Operating Environment ((OE), as well as other platforms through Java technology licensees.

Figure 1-1: The Java HotSpot Virtual Machine is the foundation for the 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, 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 version 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 (IDEs)including the Sun Open Net Environment ((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-and server-side Java VM environments.

  The Java 2 SDK, Standard Edition, contains two implementations of the Java 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.

Java HotSpot 1.4.1 incorporates new features over previous versions of the Java HotSpot Virtual Machine.These include:

• The full-speed debugging feature of the Java Platform Debugger Architecture now can be used with both the Java HotSpot Client VM and Java HotSpot Server VM. In version 1.4.0, it worked only with the Java HotSpot Client VM. Full-speed debugging enables using Java HotSpot technology -- instead of running in interpreter mode -- when debugging programs.

• New garbage collection algorithms are available. Two new garbage collectors (GC) can now be used to improve application performance. The Java HotSpot memory system offers the flexibility to use specific GC algorithms according to the needs of individual applications. In addition to the GC mechanisms available in earlier releases, this latest version of the Java HotSpot VM offers a multithreaded synchronous copying collector which works well in many multiprocessor environments, and a mostly concurrent mark-sweep collector, which improves performance in applications that require large heaps.

• Beginning with J2SE 1.4.1, the Java HotSpot Server VM does not support operation on chips with SPARC v8 architecture. The SPARCstation family of processors, including the SPARCstation Workstation, SPARCstation Classic, SPARCstation 2, SPARCstation 4, SPARCstation 5, SPARCstation 10, SPARCstation 20, and SPARCstation Voyager processors, are affected by this change. The Java HotSpot Client VM does support operation on SPARC v8 platforms. See the Java HotSpot VM documentation for information on the Server VM and Client VM. Note that UltraSPARC processors are not affected by this change.

This version of the Java HotSpot VM builds on a strong foundation of features and capabilities. The previous version incorporated many improvements in scalability,performance,reliability,and serviceability (RAS). Overall performance was significantly enhanced by using a variety of techniques, as listed below.As well, on-the-fly adaptive optimization technology, which detects and accelerates performance-critical code, has been further refined and tuned. The main areas of improvement in version 1.4.0 include:

• 64-bit support on the Solaris OE, SPARC Platform Edition: 64-bit support provides Java technology developers with near-limitless amounts of memory for high-performance, high-scalability computing. While earlier J2SE releases were limited to addressing four gigabytes of RAM, version 1.4.0 allows applications built on Java technology 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 database. The result is significantly faster processing for business intelligence, data mining, and engineering and scientific applications. Developers can take advantage of the benefits of 64-bit computing without rewriting their existing Java technology-based applications. Note that 64-bit functionality is available only on Java HotSpot Server Compiler environments and the Solaris OE.

• 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 that used in serialization. The improvements are visible when running RMI, Java Native Interface (JNI), or CORBA code environments.

• Object Serialization: The JVM also speeds 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,JNI,or CORBA code environments.

• New I/O (NIO): The NIO APIs introduced in version 1.4 provide 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,the requirement for one thread per network connection was removed. Reducing thread overhead enables more network connections. The NIO APIs supplement the I/O facilities in the java.io package. NIO introduced in version 1.4 is a subset of the changes proposed in 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.

• An 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, several subtle improvements were also made. One of the most important is in the area of generation sizing. J2SE version 1.4.0 provides improved heuristics for selecting the most efficient settings, which can have a dramatic effect on GC throughput.

• A command-line option, -Xcheck: jni, for performing additional JNI checks became available. 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 multitiered debugging architecture that allows tool developers to easily create debugger applications which run portably across platforms, VM implementations, and SDK versions. Enhancements included in version 1.4:

• Full Speed Debugging: In versions 1.3 and earlier of the Java HotSpot VM, when debugging was enabled, the program executed using only the interpreter. Full speed debugging offers the full performance advantage of HotSpot compiler technology to VM programs running with debugging enabled. The improved performance enables easier debugging of long running programs. As well, testing can proceed at full speed, and the launch of a debugger can occur on an exception.

• HotSwap Class File Replacement: This 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, developers can recompile a single class, and replace the old instance with a new instance.

• Support For Debugging Other Languages: The JPDA was extended so that non Java language source code, which is translated into Java language source or Java VM 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 print and 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 where the error occurred. The result is that developers can more easily and efficiently debug their applications. If an error message indicates a problem in the JVM code itself, it allows a developer to submit a more accurate and helpful bug report.

• Solaris OE threading scalability improvements: Java HotSpot VM can take advantage of the new thread model available for the Solaris 8 and Solaris 9 OE. The thread model maps lightweight processes (LWPs) one-to-one to Solaris OE kernel threads. This model improves stability, decreases thread starvation,provides more balanced thread scheduling,and 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 five percent); whereas with J2SE 1.3, the spread between threads doing the most and fewest operations could exceed 20 percent. This improves CPU utilization on systems with multiple CPUs 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 OE 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, or SIGILL, since those signal handlers could conflict with the signal handlers used internally by the Java HotSpot VM.

Earlier Enhancements

The Java HotSpot VM introduced many advanced capabilities in version 1.3, and these capabilities are still part of the core functionality. The most notable include:

• 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 is improved output, including a mechanism to detect if the crash was in the VM itself, or whether it was caused by user-supplied native code external to the VM.

• 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 features 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 is aware of important library functions, which results in better performance when generating code for them.

Back to Top

[Table of Contents/Page 1]  [Page 2]  [Page 3]  [Page 4]  [Page 5]