Real-time means "the ability to reliably and predictably respond to a real-world event"
Yüklə 187 Kb.
|
- Bu səhifədəki naviqasiya:
- 2.0 Limitations of standard Java
- 3.0 Java Real-Time System
- 4.0 Developer tools for Java RTS
- 5.0 Real Time Java Platform: WebSphere
- 6.0 Conclusion
- References
Overview of the Real Time JavaBy DMITRI ILKAEV 1.0 IntroductionReal-time means "the ability to reliably and predictably respond to a real-world event". So "real-time" is more about timing than speed and the ability to program a real-time solution means that developers need the appropriate support from the system in order to reason in a temporal fashion. In a more formal way real-time application development requires an API set and semantics which allow developers to correctly reason about and control the temporal behavior of applications. See below requirements to the real time systems described in [1]: Real-time requirements Real-time (RT) is a broad term used to describe applications that have real-world timing requirements. For example, a sluggish user interface doesn't satisfy an average user's generic RT requirements. This type of application is often described as a soft RT application. The same requirement might be more explicitly phrased as "the application should not take more than 0.1 seconds to respond to a mouse click." If the requirement isn't met, it's a soft failure: the application can continue, and the user, though unhappy, can still use it. In contrast, applications that must strictly meet real-world timing requirements are typically called hard RT applications. An application controlling the rudder of an airplane, for example, must not be delayed for any reason because the result could be catastrophic. What it means to be an RT application depends in large part on how tolerant the application can be to faults in the form of missed timing requirements. Another key aspect of RT requirements is response time. It's critical for programmers writing hard or soft RT applications to understand the response-time constraint. The techniques required to meet a hard 1-microsecond response are significantly different from those required to meet a hard 100-millisecond response. In practice, achieving response times below tens of microseconds requires a combination of custom hardware and software, possibly with no (or a very thin) operating-system layer. Finally, designers of robust RT applications typically need some quantifiable level of deterministic performance characteristics in order to architect an application to meet the response-time requirements. Unpredictable performance effects large enough to impact a system's ability to meet an application's response-time requirements make it difficult and maybe even impossible to architect that application properly. The designers of most RT execution environments devote considerable effort to reducing nondeterministic performance effects to meet the response-time needs of the broadest possible spectrum of RT applications.
2.0 Limitations of standard JavaStandard Java applications running on a general-purpose JVM on a general-purpose operating system can only hope to meet soft RT requirements at the level of hundreds of milliseconds. Several fundamental aspects of the language are responsible: thread management, class loading, Just-in-time (JIT) compiler activity, and garbage collection (GC). Some of these issues can be mitigated by application designers, but only with significant work, see more details in 4 part review of Real-time Java [1-4] and the core limitations are described briefly below. Thread management Standard Java provides no guarantees for thread scheduling or thread priorities. An application that must respond to events in a well-defined time has no way to ensure that another low-priority thread won't get scheduled in front of a high-priority thread. To compensate, a programmer would need to partition an application into a set of applications that the operating system can then run at different priorities. This partitioning would increase the overhead of these events and make communication between the events far more challenging. Class loading A Java-conformant JVM must delay loading a class until it's first referenced by a program. Loading a class can take a variable amount of time depending on the speed of the medium (disk or other) the class is loaded from, the class's size, and the overhead incurred by the class loaders themselves. The delay to load a class can commonly be as high as 10 milliseconds. If tens or hundreds of classes need to be loaded, the loading time itself can cause a significant and possibly unexpected delay. Careful application design can be used to load all classes at application start-up, but this must be done manually because the Java language specification doesn't let the JVM perform this step early. Garbage collection The benefits of GC to application development -- including pointer safety, leak avoidance, and freeing developers from needing to write custom memory-management tooling -- are well documented. However, GC is another source of frustration for hard RT programmers using the Java language. Garbage collects occur automatically when the Java heap has been exhausted to the point that an allocation request can't be satisfied. The application itself can also trigger a collection. On the one hand, GC is a great thing for Java programmers. Errors introduced by the need to manage memory explicitly in languages such as C and C++ are some of the most difficult problems to diagnose. Proving the absence of such errors when an application is deployed is also a fundamental challenge. One of the Java programming model's major strengths is that the JVM, not the application, performs memory management, which eliminates this burden for the application programmer. On the other hand, traditional garbage collectors can introduce long delays at times that are virtually impossible for the application programmer to predict. Delays of several hundred milliseconds are not unusual. The only way to solve this problem at the application level is to prevent GC by creating a set of objects that are reused, thereby ensuring that the Java heap memory is never exhausted. In other words, programmers solve this problem by throwing away the benefits of the managed memory by explicitly managing memory themselves. In practice, this approach generally fails because it prevents programmers from using many of the class libraries provided in the JDK and by other class vendors, which likely create many temporary objects that eventually fill up the heap. Compilation Compiling Java code to native code introduces a similar problem to class loading. Most modern JVMs initially interpret Java methods and, for only those methods that execute frequently, later compile to native code. Delayed compiling results in fast start-up and reduces the amount of compilation performed during an application's execution. But performing a task with interpreted code and performing it with compiled code can take significantly different amounts of time. For a hard RT application, the inability to predict when the compilation will occur introduces too much non-determinism to make it possible to plan the application's activities effectively. As with class loading, this problem can be mitigated by using the Compiler class to compile methods programmatically at application start-up, but maintaining such a list of methods is tedious and error prone. 3.0 Java Real-Time SystemJava RTS is not only the first commercial implementation of RTSJ, it's a very robust implementation. The Sun Java Real-Time System 2.0 (Java RTS) is a substantially enhanced release to Sun's first conformant commercial implementation of the Real-Time Specification for Java (JSR-001) [5] and following enhancement JSR-282 [6]. Implementations of the RTSJ make standard Java technology more deterministic and enable it to meet rigorous timing requirements for mission-critical real-time applications. Here are the important features and benefits offered by the RTSJ and Sun's Java RTS implementation [7]:
The RTSJ introduces the concept of two new threads: real-time threads and no-heap real-time threads (a thread which cannot be interrupted by garbage collection). These threads offer more precise scheduling than with standard Java threads. They have 28 levels of priority and unlike standard Java, their priority is strictly enforced. Real-time threads are synchronized and are not subject to so-called priority inversion situations where a lower priority thread has a block on a resource needed by a higher priority thread and thus prevents the higher priority thread from running. Rigorous testing with partners has shown that Java RTS completely avoids any priority inversions - which is crucial for mission-critical applications.
The RTSJ defines two new types of memory areas that allow real-time applications to avoid unpredictable delays commonly caused by traditional garbage collectors:
Neither immortal nor scoped memories are garbage collected, so using them avoids problems of GC interference.
The RTSJ provides two mechanisms for asynchronous communication: asynchronous event handling, and asynchronous transfer of control. Asynchronous event handlers deal with external events (known as "happenings") which can occur outside the JVM. The RTSJ is unique in that it allows developers to schedule the response to asynchronous events in order to avoid disrupting the temporal integrity of the rest of the real-time application. Asynchronous Transfer of Control (ATC) provides a carefully controlled way for one thread to interrupt another thread in a safe manner.
The RTSJ specifies several ways to specify high-resolution (nanosecond accuracy) time including absolute time and relative time.
While still maintaining security protections, the RTSJ allows direct access to physical memory. This means that device drivers can be created written entirely in Java. Previously, Java applications had to link to native code to communicate directly with the hardware. 4.0 Developer tools for Java RTSA Java RTS NetBeans module is available on the netbeans.org site. The Java RTS NetBeans module is actually a suite of three modules, each of which supports a dedicated set of features [8]:
The only difference in the development process of an application with the Java RTS NetBeans module compared to a regular NetBeans 5.0 environment is the cross-platform development, namely the remote deployment and remote execution on a target where the Sun Java Real-Time System has been installed. Unchanged Features in the NetBeans Module The basic features in the NetBeans integrated development environment (IDE) remain unchanged. For example, the following features remain identical to a standard Java SE application:
Additional Features in the NetBeans Module To support the development of a Java RTS application on a remote target, the following features have been added to the environment:
Application deployment and execution profiles. The user can record, save, import from the filesystem, and export to the filesystem various remote deployment and execution parameters, for example, the Java RTS remote target on which the application should run. 5.0 Real Time Java Platform: WebSphereWebSphere Real Time V1.0 [9] is a JRE with a SDK that enables customers to build applications with low-latency, highly predictable response times. It contains a Java Runtime Environment (JRE) with Software Development Kit (SDK) that delivers the following capabilities:
WebSphere Real Time is unique from the standard JRE included with WebSphere Application Server in several significant ways. The key to WebSphere Real Time's difference is in its design to preserve the value of the Java language and platform through "garbage collection" as a central element. It reduces or eliminates the primary source of non-determinism via its one-of-a-kind "Metronome" garbage collection technology. When using WebSphere Real Time, typical Java applications can expect average garbage collector pauses on the order of less than 1 ms. By preserving garbage collection within the Java programming model, memory management remains transparent to developers, unlike an alternative approach called "scoped memory." Scoped memory can be extremely difficult to use, introducing complexities in programming and forcing developers to determine their memory requirements prior to runtime. Further, by utilizing existing Java Standard Edition 5 class libraries, WebSphere Real Time retains the productivity and reusability aspects, which make Java so attractive. This solution also employs dynamic class loading through the use of "Java executable" (JXE) jar files for eager, fast, and compatible class loading. Ahead of time (AOT) and JIT compilation can be further used to optimize the execution environment. The JIT may be run on an asynchronous, low-priority thread, preserving processor cycles for application without an active JIT. This reduces the complexity of JIT compilation changing the performance characteristics of the application as it runs. Figure 1 summarizes the core attributes of IBM WebSphere Real Time. 
Figure 1. IBM WebSphere Real Time attributes And Figure 2 depicts its architecture stack, see more details in [10,11]. 
Figure 2. WebSphere Real Time architecture For applications that require even lower latency than provided by the real-time garbage collection, WebSphere Real Time supports the RTSJ. Programmers can use the many standard features including priority-based thread scheduling, high-resolution timers, and asynchronous event handlers. WebSphere Real Time is comprised of the following components consistent with IBM's standard JRE:
A core feature of the real-time Java environment is the underlying Open Source real-time operating system. WebSphere Real Time supports an enhanced Linux kernel using system libraries and binaries from Red Hat Enterprise Linux. IBM worked with the Linux community to develop the real-time operating system capabilities needed to obtain required performance for WebSphere Real Time and has subsequently made them available via the open source community. Previous real-time Linux efforts restricted real-time tasks to a single CPU or a subset of the CPUs on the system, or functioned as a kernel extension with the attendant restrictions in facilities available to kernel code and the lack of security protections of arbitrary code running with kernel privileges. The current approach is to enable all Linux processes to have access to all CPUs on the system. 6.0 ConclusionAs was outlined in [12] real-time Java offers a much more reliable and predictable scheduling mechanism, memory handling methods, different memory models, a more predictable threading and synchronization model, asynchronous event handling, and high-resolution time handling. It makes predictable execution the first priority in all trade-off decisions, sometimes at the expense of typical general-purpose computing performance measures. Real-time Java provides real-time capabilities for applications while still being Java, and this makes it a potential success as the first commercially available real-time flavor of Java language. Tooling and platform related support is growing together with the adoption and implementation of Java real-time in mission critical applications across multiple industries. References
Yüklə 187 Kb. Dostları ilə paylaş:
|