Survey
* Your assessment is very important for improving the workof artificial intelligence, which forms the content of this project
* Your assessment is very important for improving the workof artificial intelligence, which forms the content of this project
Productivity in Real-Time Improving Abstraction, Encapsulation, and Performance within Mixed-Mode Real-Time Java Applications Kelvin Nilsen, CTO © Aonix Real-Time Pyramid (Hierarchies and Layers) signaling Custom Hardware 10 μs Credit: paper by David Bacon in sensing ACM Queue, Feb. 2007 100 μs Hard Real-Time and/or Safety-Critical Java Perception 1 ms actuation reaction coordination 10 ms Soft Real-Time Java 100 ms tactics strategy 1s Traditional Non-Real-Time Java 10 s cognition 2 Aonix© January 2007 Productivity in Real-Time Domain of Lowest Level Software •Demands for small footprint, high throughput, predictably low latency, long battery life •“Hard Real-Time” means: –Proven compliance with all deadline constraints –Proven resource (memory, network bandwidth, other) availability –Requires •Small and simple run-time environment, and •Static behavior to enable analysis to prove reliable operation Aonix© January 2007 Productivity in Real-Time 3 Domain of Soft Real-Time • Software tends to be larger, more complex, more dynamic • Often incorporates many independently developed software modules, including COTS and open-source components • Often includes dynamic reconfiguration (class loading), data replication and redistribution, and workload rebalancing in order to implement high availability and fault tolerance • Usually defies static analysis Aonix© January 2007 Productivity in Real-Time 4 Premise One •The domains of hard real-time software and soft real-time software are so different as to require very different: –Abstraction mechanisms –Development tools –Library standards –Even programming language semantics (e.g. tracing garbage collection vs. stack-memory allocation) Aonix© January 2007 Productivity in Real-Time 5 Premise Two • As real-time systems grow in functionality, size, and complexity, it is increasingly important to enable: – Developers to select between hard real-time and soft real-time technologies for different parts of a system – Both hard real-time and soft real-time components to be efficiently and robustly combined in working systems – Strong separation of concerns between independently developed components to enable “blind” modular composition Aonix© January 2007 Productivity in Real-Time 6 Paper Focus •This paper is not about proving that you can do real-time with Java – “Obviously, you can do both soft real-time and hard realtime with the Java language.” •Deeper questions: Which approaches to soft and hard real-time with Java lead to: – The most cost savings during software development and maintenance – The most reliable and error free development – Greatest flexibility and fielded system longevity Aonix© January 2007 Productivity in Real-Time 7 The Java Concurrency Model •Traditional Java programmers are told: – Make no assumption about implementation of thread priorities or time slicing – Make no assumption about synchronization queue orders – Make no assumption about priority inversion avoidance •The Beauty: all of this “correctly written” Java software runs correctly if the Java VM implements “real-time scheduling” Aonix© January 2007 Productivity in Real-Time 8 Virtual Machine Abstractions Support Soft Real-Time •Fixed-priority preemptive scheduling, with extended priority range •Priority inheritance on all synchronization locks •Maintain all thread queues in priority order •Bounded-time implementations of interface invocations, instance-of, get-synchronization lock •Real-time garbage collection Aonix© January 2007 Productivity in Real-Time 9 Contrast with RTSJ •Soft real-time virtual machine does not support: – Scoped memory protocols – Deadline overrun detection – Cost overrun detection – Asynchronous transfer of control •We consider these features to be quite difficult to use correctly, non-portable, and/or incompatible with off-the-shelf Java software Aonix© January 2007 Productivity in Real-Time 10 Virtual Machine Configuration Support •Those responsible for deploying soft real- time systems need the ability to analyze software components empirically. The virtual machine reports “approximations” of: – CPU time spent by each thread – Cumulative CPU times consumed at each priority level – Memory allocation rates of running threads – CPU time required to perform garbage collection – Amount of memory live at end of each collection Aonix© January 2007 Productivity in Real-Time 11 Trace of Garbage Collection Pacing Preemption of GC by higher priority Preemption of GC bynon-Java higher threads Priority Java threads 100% 30 80% 60% 20 40% 10 20% 550 600 650 700 Real Time (seconds) Aonix© January 2007 Productivity in Real-Time 12 Configuration of the Pacing Agent • Priority of garbage collection (GC) thread • Lowest priority at which real-time application threads run – Heuristic: under transient overload, the garbage collector will steal additional CPU cycles below this priority • Percentage of CPU time budgeted to real-time threads above the GC priority • Percentage of CPU time budgeted to real-time threads below the GC priority • Shortest relative deadline M of real-time threads at priority lower than the GC priority – The pacing agent divides the total GC effort into increments, taking no more than N% of each M time units Aonix© January 2007 Productivity in Real-Time 13 Robustness Under Normal Configuration • Garbage collection can be preempted in approximately 100 µs • Pacing heuristic attempts to predict the future based on recent history – this is not fool proof – Source code for pacing agent is supplied - customize if necessary to model “your favorite application” – If GC falls behind allocation pace, GC inherits priority of allocating thread • Threads that have most demanding latency requirements avoid memory allocation and run at priority above GC – Will never experience unbounded priority inversion with GC Aonix© January 2007 Productivity in Real-Time 14 Demonstrated Relevance •Telecommunications: fiber-optic switches, DSL broadband servers, television broadcast •Industrial Automation: semiconductor manufacturing, oil exploration, power plants •Aerospace: unmanned aircraft, satellites •Defense: next-generation artillery, infantry PDA, unmanned autonomous land vehicles, Aegis warship Aonix© January 2007 Productivity in Real-Time 15 Combining Hard and Soft Real-Time •For lowest level software, we recommend a small subset of RTSJ, patterned after the current work of JSR-302 (not discussed here) •The challenge: – If you have an application that includes both low-level software and high-level software, what is the “best” way to combine these together? Aonix© January 2007 Productivity in Real-Time 16 Options •Use Java for high-level software, and C for low-level software, connected with JNI •Use Java for high-level software, and NoHeapRealtimeThread for low-level software, connected with wait-free queues •Use the alternative protocol described here Aonix© January 2007 Productivity in Real-Time 17 Java and C with JNI •Difficulties: – There is a run-time overhead associated with each call across the boundary between JNI and C – C code integrated with Java code compromises the Java security model •Many Aonix customers report that the C/Java interface is the single most problematic source of errors in their embedded real-time systems Aonix© January 2007 Productivity in Real-Time 18 Java and NoHeapRealTimeThread •NoHeapRealtimeThread and wait-free queues enable hard real-time determinism and cooperation between high- and low-level software •However: – RTSJ Java runs slower and bigger than traditional Java – The wait-free queue abstraction introduces additional polling inefficiencies and handoff delays – Requires full trust regarding the other side of the queue Aonix© January 2007 Productivity in Real-Time 19 Cooperating HRT Components Hard Real-Time Execution Engine Traditional Java Virtual Machine Aonix© January 2007 Productivity in Real-Time 20 TraditionalJava Registry TraditionalJava Aonix© January 2007 TraditionalJava.publish(“deviceXYZ”, x) Productivity in Real-Time 21 TraditionalJava Registry “Hard Real-Time Domain” Aonix© January 2007 HardRealTimeDomain.lookup(“deviceXYZ”) Productivity in Real-Time 22 Contrast With Wait-Free Queues • The semantic models are kept entirely separate – Libraries for hard real-time are different than libraries for soft real-time – No implementation/verification complexities because of mixing immortal, GC, and scoped memory • Byte code verification of each world statically maintains referential integrity • Either world can block waiting for communication from the other world, but always under full control of the hard real-time programmer – Hard real-time programmer is assumed more “trustworthy” Aonix© January 2007 Productivity in Real-Time 23 All Java Solution Twice as Fast as C/Java! • At ESC Silicon Valley 2007, Aonix demonstrated all Java application runs over twice as fast as hybrid solution comprised of Java and C • Further benefit: all Java Aonix© January 2007 solution is easier to develop and maintain, offering superior separation of concerns Productivity in Real-Time 24 24 Summary •Market adoption of Java for “mainstream” development has been driven largely by improvements in: – Reliability, modularity, scalability, portability, generality, flexibility, reusability, etc. •If we intend to enable similar adoption of Java by the embedded real-time community, we must deliver similar benefits •This paper describes progress towards this end Aonix© January 2007 Productivity in Real-Time 25