Transcript slides

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