Real-time Java, part 1th: Using the Java language to write real-time systems

For many important reasons, the Java language is very limited in its application in real time systems. These include uncertainties inherent in the design of the Java language, such as dynamic class loading, and the uncertain performance impact of the Java Runtime Environment (Java Runtime ENVIRONMENT,JRE) itself, such as garbage Collectors and local code compilation. Real-time specification for Java (RTSJ) is an open specification that further enhances the openness of the Java language so that it can be used to build real-time systems (see Resources). To implement the RTSJ specification, support for the operating system, JRE, and Java class libraries (Java Classes LIBRARY,JCL) is required. This article explores the challenges of using the Java language to implement real-time systems and describes the development kits and runtime environments that can address these challenges. The following articles in this series will further explain the concepts and techniques described in this article.

Real-time requirements

Real-time (RT) is a broad term used to describe applications that need to be synchronized with the real world. For example, a slow-response user interface does not meet the normal RT requirements of the average user. This type of application is often referred to as a soft RT application. "The application cannot respond more than 0.1 seconds to a mouse click", which may be more clearly stated. If this requirement is not met, then this is a soft fault: The application can continue to run, although the user is not happy, but still can use it. In contrast, applications that have to be strictly responsive to real-time synchronization requirements are often referred to as hard RT applications. For example, an application that controls the direction of an aircraft can have no delay for any reason, otherwise it will lead to disastrous consequences. The meaning of an RT application is largely dependent on the application's degree of fault tolerance, which is considered an error when it deviates from real-time requirements.

Another key factor in RT requirements is response time. For programmers who write hard or soft RT applications, it is important to understand the constraints of response time. technologies that require a 1-microsecond hard response are very different from those that require a 100-millisecond hard response. In practice, to make the response time less than dozens of microseconds requires a combination of custom hardware and software, most likely not (or has a very thin) operating system layer.

Finally, the designers of robust RT applications often need measurable, determined performance features to design applications that meet response time requirements. Unpredictable performance impacts are so severe that the system cannot meet the requirements of application response times, making it difficult (or impossible) to design the application correctly. The designers of most RT execution environments devote a lot of effort to reducing the uncertainty performance impact to meet the response time requirements of the largest RT application.

The challenges facing RT Java applications

In a general-purpose operating system, a standard Java application running on a common JVM can only expect to meet the hundreds of-millisecond level of soft RT requirements. The reasons relate to several basic aspects of the language: thread management, class loading, Just-in-time (JIT) compilation activity, and garbage collection (garbage COLLECTION,GC). The application designer can mitigate some of these problems, but it takes a lot of work.

Thread Management

The standard Java language does not provide any guarantees for thread scheduling and thread prioritization. An application that must respond to events within a precise time cannot ensure that another low-priority thread is not scheduled before a high priority line. To remedy this shortcoming, the programmer needs to divide the application into a set of child applications so that the operating system can run at different priority levels. This division increases the overhead of the event and makes communication between events more difficult.

Class load

A JVM that is consistent with Java must delay loading the class until the program references it for the first time. Classes load at different times depending on the speed of the media (disk or other) on which the class is loaded, the size of the class, and the cost of the class loader itself. Load classes typically have a latency of up to 10 milliseconds. If you need to load dozens of or hundreds of classes, the load time itself can cause a very long time of unexpected delay. Carefully design the application so that the application loads all classes at startup, but this must be done manually because the Java language specification does not allow the JVM to perform this step ahead of time.

Garbage collection

The benefits of GC in application development-including pointer security, avoiding memory leaks, and freeing developers from writing custom memory management tools-have been well documented. However, for hard RT programmers who use the Java language, the GC is another reason for their frustration. Garbage collection occurs automatically when the Java heap is exhausted and the allocation request is still not satisfied. The application itself can also trigger garbage collection.

On the one hand, GC is very good for Java programmers. In languages such as C and C + +, errors caused by the need to explicitly manage memory are some of the most difficult problems to diagnose. Testing for this type of error is also a fundamental challenge when deploying applications. One of the main advantages of the Java programming model is that memory management is performed by the JVM rather than by the application, which removes this burden for application programmers.

On the other hand, traditional garbage collectors can lead to long delays, and it is almost impossible for application programmers to predict this time. A hundreds of millisecond delay is not uncommon. The only way to solve this problem on the application layer is to block the GC by creating a set of reusable objects, ensuring that the memory of the Java heap is not depleted. In other words, the programmer abandons the advantage of using the JVM to manage memory, but solves the problem by explicitly managing the memory personally. In practice, this method usually does not work because it prevents programmers from using the many class libraries provided by the JDK and other class vendors, which may create a large number of temporary objects that will eventually fill the heap.