Use real-time Java for Development, part 2nd improving service quality

Variability in Java applications (usually caused by pauses or delays, which can occur in unpredictable times) may occur throughout the software stack. Latency can be caused by the following factors:

Hardware (during cache)

Firmware (during processing of system management interrupts such as CPU temperature data)

Operating system (in response to an interrupt or background activity that performs periodic scheduling)

Other programs running on the same system

JVM (Garbage Collection, Just-in-time compilation, and class loading)

The Java application itself

It is difficult to compensate for delays at the lower levels at a higher level, so if you try to resolve variability only at the application level, you may have just shifted the JVM or OS latency without solving the actual problem. Fortunately, lower-level delays may be relatively short on high-level delays, so you need to dive deeper into lower levels than the JVM or OS only if the need to reduce variability is very strong. If the requirements are not so strong, you can focus on the JVM level or the application.

Real-time Java provides the tools necessary to intercept the volatile sources in the JVM and applications and deliver the quality of service required by the user. This article details the variability sources at the JVM and application levels, and describes the tools and techniques that can be used to mitigate their impact. Then introduce a simple Java server application to illustrate some of these concepts.

Address the source of variability

Variability in the JVM derives primarily from the dynamic nature of the Java language:

Memory is never explicitly released by an application, but is periodically recycled by the garbage collector.

Class is parsed when it is first used by an application.

Native code is compiled (and can be recompiled) by the Just-in-time (JIT) compiler when the application is run, based on frequently invoked classes and methods.

At the Java application level, thread management is a key area associated with variability.

Garbage collection paused

When the garbage collector reclaims the memory that the program no longer uses, it can stop any application thread. (This type of collector is called a Stop-the-world or STW collector). Or it can perform some of its work with the application at the same time. In either case, the resources that the garbage collector needs are not available to the application, so it is well known that garbage collection (GC) is the source of pause and variability in Java application performance. Although many GC models have their own advantages and disadvantages, when the goal of the application is to shorten GC pauses, the two main choices will be generational (generational) and real-time collectors.

The generational collector organizes the heap into at least two parts, which are often referred to as new and old (sometimes called reserved) spaces. New objects are always allocated in the new space. When the new space runs out of free memory, it will only be garbage collected in that space. Using a relatively small new space may have a shorter GC cycle. Objects that remain in the process of multiple new space garbage collection are elevated to the old space. Old space garbage collection occurs often much less frequently than new space garbage collection, but these GC cycles may be much longer because the old space is much larger than the new space. The generational garbage collector provides a relatively short average GC pause time, but the overhead of the old space collection may cause the standard deviation of these pause times to be very large. The generational collector is most effective for applications that do not frequently change the active dataset but produce large amounts of garbage. In this scenario, the old space collection rarely occurs, so the GC pause time depends on the short new space collection time.

In contrast to the generational collector, the real time garbage collector controls its own behavior to significantly shorten the length of the GC cycle (by executing cycles when the application is idle) or to mitigate the impact of these cycles on application performance by performing work in smaller increments based on a "contract" between the applications. With this type of collector, you can predict the worst case scenario for a particular task. For example, the garbage collector in the Ibm®websphere®real-time JVM divides GC cycles into smaller pieces of work, called GC limits, which can be done incrementally. The scheduling of quotas has minimal impact on application performance, with a delay of up to hundreds of microseconds, typically less than 1 milliseconds. To achieve this level of latency, the garbage collector must be able to plan its own work by introducing the concept of the contract to the application. This contract manages how often the GC interrupts the execution of an application. For example, the default utilization contract is 70%, that is, when running on a live operating system, only the GC is allowed to use up to 3 milliseconds per 10 milliseconds, typically a pause of approximately 500 microseconds. (See "Live Java, Part 4: Live garbage Collection" For a detailed description of the IBM WebSphere real time Garbage collector operation).

Heap size and application utilization are important tuning preferences to consider when running applications on the live garbage collector. As application utilization increases, the garbage collector completes its work for a shorter period of time, requiring a larger heap to ensure that the GC cycle can be incrementally completed. If the garbage collector cannot keep up with the allocation speed, GC will use synchronous collection.

For example, applications running on the IBM WebSphere real-time JVM (with 70% of the default application utilization contract) require a larger heap by default than when running on a JVM that uses the generational garbage collector (not provided with a contract). Because the real-time garbage collector controls the length of the GC pause time, increasing the heap size reduces the GC frequency and does not prolong the pause times. On the other hand, in a non-real-time garbage collector, increasing the heap size usually reduces the frequency of the GC cycle, which reduces the overall impact of the garbage collector. When garbage collection occurs, the pause time is usually longer (because a larger heap needs to be checked).

In the IBM WebSphere real time JVM, you can use the-xmx<size> option to adjust the heap size. For example,-xmx512m specifies a heap size of 512MB. You can also adjust application utilization. For example,-xgc:targetutilization=80 sets the utilization rate to 80%.