使用Java语言编写实时系统.doc

使用 Java 语言编写实时系统本文是关于实时 Java 的系列文章（共 5 部分）的第一篇，描述了使用 Java 语言开发能够满足实时性能需求的系统的过程中遇到的主要挑战。全面概述了实时应用程序开发的意义，以及如何设计运行时系统以满足实时应用程序的需求。作者介绍了一个实现，该实现通过组合一些基于标准的技术解决了实时 Java 带来的挑战。实时需求Real-time (RT) 是一个含义广泛的术语，用来描述需要与真实世界同步的应用程序。比如，一个反应缓慢的用户界面不能够满足一般用户的正常 RT 需求。这类应用程序通常被称为软 RT 应用程序。“应用程序对鼠标单击的反应时间不能超过 0.1 秒”，这样表述可能更明白一些。如果不能满足这种需求，那么这就是一个软故障：应用程序可以继续运行，尽管用户不高兴，但仍然能使用它。相比之下，那些必须严格地满足实时同步需求的应用程序通常被称为硬 RT 应用程序。比方说，控制飞机方向的应用程序不能够有任何原因的延迟，否则将导致灾难性的后果。RT 应用程序的含义很大程度上取决于应用程序的容错程度，即偏离实时需求到何种程度时会被认为是错误。 RT 需求的另一个关键因素是响应时间。对于编写硬或软 RT 应用程序的编程人员来说，理解响应时间的约束至关重要。要求满足 1 微秒硬响应的技术与那些要求满足 100 毫秒硬响应的技术截然不同。在实践中，要使响应时间小于几十微秒，需要组合定制的软硬件，很可能没有（或者有非常薄的）操作系统层。 最后，健壮 RT 应用程序的设计者通常需要一些可计量的确定的性能特征，以便设计能够满足响应时间需求的应用程序。不可预测的性能影响非常严重，致使系统无法满足应用程序响应时间的要求，因此难于（或者根本不可能）正确地设计应用程序。大多数 RT 执行环境的设计者投入了很多精力来减少不确定性性能影响，来满足最大范围内 RT 应用程序的响应时间需求。 RT 中的本地代码编译大多数现代 JVM 结合使用了解释和编译的代码执行。为了消除解释的高性能代价，JIT 编译器选择将频繁执行的代码直接转换为 CPU 的本地指令。Java 语言的动态特性通常会将编译器的操作作为程序执行，而不是作为发生在程序运行前的一个步骤（C+ 或 Fortran 语言中就属于后一情形）。JIT 编译器将选择它要编译的代码，这样它花费的编译时间很可能通过对代码性能的改进得到补偿。在动态编译行为的最顶层，传统 JIT 编译器使用了大量的推测性优化，这些优化利用了正在运行程序的动态特性，这对于应用程序执行的某个阶段中的一点也许是正确的，但是不一定适合整个应用程序的执行阶段。如果对于该特性的假设稍后变为错误，那么这种优化是 “未完成的”。 在传统的非 RT 环境中，在程序执行时编译代码效果非常好，因为大部分的编译器操作对应用程序性能是透明的。然而，在 RT 环境中，JIT 编译器引入了不可预知的运行时行为，这将严重影响最坏情况时执行时间分析。但是这种环境中，编译的代码的性能优势仍然非常重要，因为它能够使更复杂的任务在较短的时间内完成。 WebSphere Real Time 引入了两种解决方案在不同的折中点平衡这两种需求。第一个解决方案是使用 JIT 编译器，在较低的非 RT 优先级上运行，它已被修改为很少执行主动的推测性优化。非 RT 优先级的操作使操作系统保证编译器不会干扰 RT 任务的执行。但是，代码性能会随时间改变这一事实是一种不确定影响，这使得这种解决方案更适合于软 RT 环境而不适合硬 RT 环境。 对于硬 RT 环境来说，WebSphere Real Time 引入了 AOT，用于应用程序编程。存储在 JAR 文件中的 Java 类文件可以通过简单的命令行预编译为 Java eXEcutable (JXE) 文件。通过将这些 JXE 文件（而不是原始的 JAR 文件）指定到应用程序类路径中，将能够使应用程序得到调用，因此就执行了 AOT 编译的代码 而不是经解释过的字节码或 JIT 编译器编译过的本地代码。在第一个 WebSphere Real Time 发布版中，使用 AOT 代码意味着没有使用 JIT 编译器，这样有两个主要的好处：更低的内存消耗以及不会受到来自 JIT 编译线程和样例线程的动态性能影响，这些线程用来标识频繁执行的代码。 图 1 展示了在使用 AOT 代码时，在 WebSphere Real Time 中如何执行 Java 代码：图 1. 如何使用 AOT 代码首先看图 1 的左上方，和任何 Java 开发项目一样，开发人员将 Java 源代码编译成类文件，类文件被绑定到 JAR 文件，然后由 AOT 使用 jxeinajar 工具对其进行编译。这个工具可以编译 JAR 文件中所有类的所有方法，也可以根据一个基于 JIT 的样例程序的执行输出选择性地编译某些方法，这个程序标识了需要编译的最重要的方法。jxeinajar 工具编译 JAR 文件中的方法并构造一个 JXE 文件，后者包含原始 JAR 文件的内容以及 AOT 编译器生成的本地代码。在执行程序时，JXE 文件可以直接取代 JAR 文件。如果使用 -Xnojit 选项调用 JVM，那么将加载类路径中 JXE 文件的 AOT 编译的代码（根据 Java 语言的规则）。在程序执行期间，将对从 JAR 文件加载的方法或者从 JXE 文件加载的未经编译的方法进行解释。将从 JXE 中加载的编译了的方法作为本地代码执行。在图 1中，同样还需要使用 -Xrealtime 命令行选项指定应该调用 RT VM。该命令行选项只有在 WebSphere Real Time 中可用。 AOT 代码的缺点尽管 AOT 代码能够产生更确定的性能，它同样具有一些缺点。用于存储 AOT 代码的 JXE 文件通常要比存放类文件的 JAR 文件大很多，这是因为本地代码一般要比存储在类文件中的字节码密度小。执行本地代码还需要各种补充数据，用以描述如何将代码绑定到 JVM 以及如何捕获异常（比如），从而执行代码。第二个缺点是，尽管 AOT 编译过的代码比解释过的代码执行速度快，但是却比 JIT 编译的代码慢得多。最后一点，将解释的方法转换为编译的方法所用的时间（反之亦然）要比从其他解释方法调用一种解释方法（或从其他编译的方法调用编译方法）要长。在具有活动 JIT 编译器的 JVM 中，会通过不断编译编译代码的 “边缘部分” ，直到转换次数不会影响性能为止，最终消除这种代价。在具有 AOT 编译代码而没有 JIT 编译器的 JVM 中，转换次数是由被编译到 JXE 中的方法决定的。因此，我们通常推荐使用 AOT 编译整个应用程序以及应用程序所依赖的 Java 库类。正如上文提到的，扩展编译了的方法的数量将影响内存消耗，尽管性能从中获得的好处往往要比增加内存消耗更重要。 未来发展方向在可预测性能和原始吞吐量方面，需要做更多的工作以加快 RT Java 环境。必须对 Java 语言实现两个关键领域的改进，从而使其在 RT 应用程序领域内获得成功： 为运行传统操作系统而希望获得更好的预测性的用户提供 RT 技术。 使 RT 技术简单易用。 面向软 RTWebSphere Real Time 的很多特性对以传统操作系统为目标的编程人员非常有用。增量 GC 和基于优先级的线程必定会在大量应用程序中得到应用，即使只能够提供软 RT 性能而不能保证硬 RT 的实现。比如，对于多数开发人员来说，提供可预测性能而不会出现不可预测的 GC 延迟的应用服务器是个非常有吸引力的想法。类似地，使用合理的调度目标，使应用程序运行高优先级并良好监视的 Java 线程将简化 Java 服务器的开发。 令 RT 更加简单对于开发人员来说，将 Java 语言的优点引入 RT 系统的创建中将带来非常大的优势。但是，始终有要改善的地方，并且我们不断开发新的特性来进一步简化 RT 编程。您可以访问 IBM alphaWorks 站点试用我们研究的实时线程研究技术，它能够使开发人员管理使用非常频繁的事件，而这些事件对变化或延迟的要求很高（参见 参考资料）。通过预加载、预初始化以及预编译代码处理事件，然后使用比 RTSJ 中的 NHRT 更少的繁琐限制运行独立于垃圾收集器的代码，从而实现更具确定性的行为。您还将发现名为 TuningFork 的工具，它用来跟踪从操作系统到 JVM，再到应用程序内部的路径，能够更轻松地执行详细的性能分析。 Using the Java language for real-time systemsThis article, the first in a six-part series on real-time Java, describes the key challenges to using the Java language to develop systems that meet real-time performance requirements. It presents a broad overview of what real-time application development means and how runtime systems must be engineered to meet the requirements of real-time applications. The authors introduce an implementation that addresses real-time Java challenges through a combination of standards-based technologies. Real-time requirementsReal-time (RT) is a broad term used to describe applications that have real-world timing requirements. For example, a sluggish user interface doesnt satisfy an average users 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 isnt met, its 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. Its 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 systems ability to meet an applications 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. Native code compilation for RTMost modern JVMs use a combination of interpretation and compiled code execution. To eliminate interpretations high performance cost, a JIT compiler selects frequently executed code to be translated directly to the CPUs native instructions. The Java languages dynamic characteristics typically cause this compiler to operate as the program executes rather than as a step that occurs before the program is run (as is the case for languages like C+ or Fortran). The JIT compiler is selective about which code it compiles so that the time it takes to do the compilation is likely to be made up by the improvements to the codes performance. On top of this dynamic compilation behaviour, traditional JIT compilers employ a variety of speculative optimizations that exploit dynamic characteristics of the running program that might be true at one point during one particular programs execution but might not remain true for the duration of execution. Such optimizations can be undone if the assumption about this characteristic later becomes false. In a traditional non-RT environment, compiling code while the program executes works well because the compilers actions are mostly transparent to the applications performance. In an RT environment, however, the JIT compiler introduces an unpredictable run-time behaviour that wreaks havoc on worst-case execution time analysis. But the performance benefit of compiled code is still important in this environment because it enables more-complex tasks to complete in shorter periods of time. WebSphere Real Time introduces two solutions to balance these two requirements at different trade-off points. The first solution is to employ a JIT compiler, operating at a low non-RT priority, that has been modified to perform fewer aggressively speculative optimizations. Operation at a non-RT priority lets the operating system guarantee that the compiler will never interfere with the execution of a RT task. Nonetheless, the fact that the code performance will change over time is a nondeterministic effect that makes this solution more appropriate for softer RT environments rather than hard RT environments. For harder RT environments, WebSphere Real Time introduces AOT compilation for application programs. Java class files stored in JAR files can be precompiled through a simple command line into Java eXEcutable (JXE) files. By specifying these JXE files, rather than the original JAR files, on the application classpath, the application can be invoked so that the AOT-compiled code is executed - rather than bytecodes being interpreted or native code being compiled by a JIT compiler. In the first WebSphere Real Time release, using AOT code means that no JIT compiler is present, which has two primary advantages: lower memory consumption and no dynamic performance impact from either the JIT compilation thread or the sampling thread that identifies frequently executing code. Figure 1 shows how Java code executes in WebSphere Real Time when AOT code is being used: Figure 1. How AOT code is usedStarting at the upper left of Figure 5, the developer compiles Java source code to class files as in any Java development project. Class files are bundled into JAR files, which are then AOT compiled using the jxeinajar tool. This tool can either compile all the methods in all the classes in the JAR files, or it can selectively compile some of the methods based on output generated by a sample JIT-based execution of the program that identifies the most important methods to compile. The jxeinajar tool compiles the methods in a JAR file and constructs a JXE file that contains both the contents of the original JAR file and the native code generated by the AOT compiler. The JXE files can be directly substituted for JAR files when the program is executed. If the JVM is invoked with the -Xnojit option, then the AOT-compiled code in JXE files on the classpath is loaded (according to the rules of the Java language). During program execution, methods loaded from JAR files or uncompiled methods loaded from JXE files are interpreted. Compiled methods loaded from JXEs execute as native code. In Figure 5, the -Xrealtime command-line option is also necessary to specify that the RT VM should be invoked. This command-line option is only available in WebSphere Real Time. Disadvantages of AOT codeAlthough AOT code enables more-deterministic performance, it also has some disadvantages. The JXEs used to store AOT code are generally much larger than the JAR files that hold the class files because native code is generally less dense than the bytecodes stored in class files. Native code execution also requires a variety of supplementary data to describe how the code needs to be bound into a JVM and how to catch exceptions, for example, so that the code can be executed. A second disadvantage is that AOT-compiled code, though faster than interpreted code, can be substantially slower than JIT-compiled code. Finally, the time to transition between an interpreted method and a compiled method, or vice versa, is higher than the time to call an interpreted method from another interpreted method or to call a compiled method from a compiled method. In a JVM with an active JIT compiler, this cost is eventually eliminated by compiling around the edges of the compiled code until the number of transitions is too small to impact performance. In a JVM with AOT-compiled code but no JIT compiler, the number of transitions is determined by the set of methods that were compiled into the JXEs. For this reason, we typically recommend AOT compiling the entire application as well as the Java library classes on which the application depends. Expanding the number of compiled methods, as we mentioned above, has a footprint impact although the benefit to performance is usually more critical than the footprint increase. Future directionsMore can be done to make an RT Java environment faster, in terms of both predictable performance and raw throughput. We see two key areas of advancement that must occur for the Java language to succeed in the RT application space: Provide RT technology to users who want better predictability while running on traditional operating systems. Make it much easier to use this technology. Toward soft RTMany features of WebSphere Real Time are useful to programmers targeting a traditional operating system. Incremental GC and priority-based thread