Show TOC

Background documentationArchitecture of SAP JVM Locate this document in the navigation structure

 

Basic SAP JVM Architecture

The SAP JVM is basically structured into two parts: the J2SE class library and the VM.

Basic SAP JVM Architecture (Basic SAP JVM Architecture)

  • The J2SE class library contains the Java libraries as required by the Java SE specification. From a Java application perspective, the class library is the main entry point into the SAP JVM.

  • The VM constitutes the runtime environment for Java applications and is responsible for executing the Java byte code. It provides native interfaces for the implementation of the J2SE class library and for native applications (such as third party profiler implementations using the Java Virtual Machine Tool Interface JVMTI).

Both the VM and J2SE class library contain platform specific code. The J2SE class library uses operating system specific interfaces mainly for implementing the user interface (UI) and I/O services. The VM depends on the operating system layer (for example, for implementing the Java thread system) and, in particular, the code generated from the just-in-time (JIT) compiler depends on the CPU architecture.

J2SE Class Library

The J2SE class library ranges from basic Java utility functionality (for example, basic data structures and XML parser functionality) over low level system features (for example, threading infrastructure and lock handling) up to a complete UI layer. An extract of these libraries is shown in the following figure.

J2SE Class Library (J2SE Class Library)

In order to implement parts of this functionality (for example the file and thread system, AWT) access to the operating system (OS) interface is needed. For native resources which have to be managed by the VM runtime, the VM itself provides the necessary interfaces for the J2SE class library. For example, Java threads and the OS threads utilized for them are created and managed by the VM. However, the native parts of the UI implementation are implemented by directly accessing the OS interface without interfering with the VM. The Hotspot Platform Interface (HPI) provides an abstraction over some OS resources directly accessed by the J2SE class library implementation.

As already stated the SAP JVM has been designed for server-side applications. Thus support for sound and printing has been removed from the delivery. The Abstract Window Toolkit (AWT) and Swing are the J2SE standard API for providing graphical user interfaces with Java programs. In order to provide a fully-certified Java VM, the AWT/Swing functionality has to be implemented. Therefore the SAP JVM contains a full AWT/Swing implementation on all supported platforms, although SAP does not provide support for AWT or other UI based applications (except for tools provided by SAP with the SAP NetWeaver Application Server Java).

In addition to the libraries already provided by Sun, a supportability library for better monitoring the SAP NetWeaver Application Server Java and its applications has been added by SAP (the supportability library is meant for use by SAP products only). It contains Java interfaces for the features already mentioned in SAP JVM: switching to debugging on demand, restricted debugging, comprehensive monitoring information, and several traces for important VM parts. Note that the actual implementation of these features is done inside the VM layer. The J2SE class library just contains a small wrapper around the native interface.

VM Architecture

The basic architecture of the SAP JVM is shown in the following figure.

SAP JVM Architecture (SAP JVM Architecture)

The runtime environment contains all the core components necessary for executing Java byte codes. To provide the semantics of the Java language specification, several low level components like a system for managing Java threads are available. Java byte codes are stored in so-called class files defined by the VM specification. The class loading system dynamically loads, links, and initializes classes and interfaces. The loaded byte codes are then emulated by a byte code interpreter.

JIT Compiler

In order to speed up the execution time of a Java program, a just-in-time (JIT) compiler exists that translates the byte codes into native machine code on-the-fly. Rather than compiling method-by-method the SAP JVM runs the program immediately using an interpreter. It analyzes the code as it runs to detect the critical “hot spots” in the program. Then the SAP JVM focuses the attention of a global native-code compiler and optimizer on these hot spots. By avoiding compilation of infrequently executed code (most of the program), the compiler can devote much more attention to the performance-critical parts of the program, without necessarily increasing the overall compilation time. This hotspot monitoring is continued dynamically as the program runs, so that it literally adapts its performance on-the-fly to the needs of the user.

The JIT compiler does not only provide functionality to compile byte codes into native code blobs, it also contains techniques for switching back from compiled code to the interpreter. This “deoptimization” allows the compiler to perform aggressive optimizations that speed up the normal execution, but may lead to situations where the optimization was too optimistic and must therefore be undone. It is also a prerequisite for providing the debugging-on-demand functionality.

Sun’s HotSpot VM comes with two flavors of JIT compilers. The client compiler is tuned for the performance profile of typical client applications, whereas the server compiler focuses on the performance profile of typical server applications. The SAP JVM is built and optimized for server environments and therefore does not support the client compiler.

Garbage Collection

A major attraction of the Java programming is that it provides a built-in automatic memory management, or “garbage collection”. In traditional languages, dynamic memory allocation is done using an explicit allocate/free model. By contract, a garbage collector automatically handles freeing of unused object memory behind the scenes by only reclaiming an object when it can prove that the object is no longer accessible to the running program. The Sun HotSpot VM comes with several garbage collector algorithms suitable for distinct use cases. For example, there are algorithms optimized for high-throughput or low-pause times. The SAP JVM supports a subset of these algorithms, which are suitable for application server scenarios.

JVMTI and Profiling

In order to facilitate the implementation of supportability tools like profilers and debuggers, the VM provides the implementation of the JVMTI specification. This interface allows an external tool to inspect the state and to control the execution of applications running inside the VM.

In addition to the JVMTI implementation, the SAP JVM comes with its own profiling back end, which is optimized for SAP’s large-scale Java applications. The profiling back end contains traces for analyzing memory and performance related issues. For more information about additional supportability tools and the SAP JVM profiler front end, see Provided Tools.