fVM: a hard real-time Java implementation
for cyber-physical systems
Ensuring reliability and security of mission-critical cyberphysical systems requires a complete rethinking of the
entire software process. Over the last couple of years,
managed languages such as Java and C# have made
inroads in the soft-real-time area due to their support for
concurrency and higher levels of safety and assurance.
In particular, fVM aims to have throughput and features comparable to
production non-real-time Java virtual machines while allowing code to
run in systems smaller than currently possible. For example, fVM would
allow Java code to run on an ERC32 system with 4MB RAM.
fVM's performance comes from the use of modern compiler and static
analysis technologies such as:
•SSA-based intermediate representation
•0CFA whole-program analysis
•Aggressive inlining of small methods
•Devirtualization of most virtual/interface method calls
The fVM runtime is designed to be minimal and unobtrusive. Java
threads are implemented as OS threads, leading to lower footprint and
lower latencies. Multi-core systems can be exploited transparently.
When running in ahead-of-time mode, the only large component is the
garbage collector.
A sample Real-time Java application: the first to integrate
real-time Java on the ScanEagle Unmanned Aerial Vehicle.
The flight hardware/software set up was an Embedded
Planet PowerPC
8260
processor running
Kestrel
Institute,
September
2005 at 300MHz with
256Mb SDRAM and 32 Mb FLASH. The operating system
is Embedded Linux.
fVM goals and features:
Runtime System
Java Source
Code
Java Bytecode
Systems LLC
Automatic memory management, or garbage collection,
is difficult if hard time and space constraints must be
obeyed.
Existing real-time garbage collectors either
guarantee timing constraints at the expense of space
constraints (like IBM Websphere RT) or space constraints
at the expense of time-predictability (like Sun Java RTS,
and others). fVM is the first to guarantee both, using the
Hybrid Fragmenting Garbage Collector (HFGC).
Fragmenting Policy
Ovm
fVM
rel
Semi-Space Policy
The HFGC combines a JamaicaVM-style fragmenting
policy for payload data (object contents, array elements),
and a Cheng-Blelloch-style semi-space policy for array
spines. This bounds array accesses to a maximum of two
loads, while guaranteeing a worst-case 25% space
overhead.
javac
Program Heap
1
Bytecode parsing and type
inference
fVM Compiler
fVM aims to be an open-source production-strength
version of the Ovm research virtual machine developed by
Vitek et al at Purdue's S3 Lab. Ovm was the first real-time
Java implementation to hava successful UAV flight test (see
above).
Host System
Fiji
Filip Pizlo
Lukasz Ziarek
Jan Vitek
fVM SSA HIR
0.9
SSA optimizations and
inlining
Lowering (calling convention,
object model, exceptions, etc.)
fVM SSA LIR
SSA optimizations
Compiled Java Code
0.8
Code generation
•Base system footprint less than 500KB
fVM Garbage Collector
fVM SCJ
fVM OS interface
•High-performance ahead-of-time compilation
ANSI C
GCC
Operating System
•Multi-core support.
•Deterministic, low-overhead real-time garbage collection
fVM ahead-of-time compiler design. Java source code is compiled to
•Low start-up time
bytecode using Sun's javac or any suitable Java compiler. Bytecode is
•Portability
passed to the fVM compiler, fvmc, which outputs portable C89 code.
•Full support for Safety-Critical Java and Real-time
fvmc then invokes GCC to produce a binary for a particular platform. The
Specification for Java
binary contains the garbage collector, Safety Critical Java libraries, and an
•Compliance with Java 1.6
OS interface layer. Currently supported operating systems are Linux and
•Full JNI 1.4 support
RTEMS.
•Classloading
0.7
0.6
compress
db
mpegaudio AVERAGE
fVM Execution Time Relative to Ovm
Status of fVM. On the benchmarks we currently
support, fVM runs 14% faster than Ovm. We see speedups on all benchmarks we have tested so far. The
components that still need to be implemented include
the garbage collector and PIP/PCEP locking.