1
|
- Kelvin Nilsen, CTO
June 9, 2004
|
2
|
- Introduction and Motivation
- Real-Time Java Standards
- Overview
- Firm Real-Time
- Hard Real-Time
- Some experience reports
|
3
|
- Many experiments have concluded that Java developers are at least twice
as productive as C or C++ developers. Why?
- Stronger type checking reduces programmer errors
- Object-oriented encapsulation reduces interference between
independently developed components
- Forced exception handling reduces programmer errors
- Automatic garbage collection simplifies memory management and reduces
programmer errors
- Simpler language reduces programmer misunderstandings
- Improved portability allows programmers to master the language, rather
than mastering particular tool chains and RTOS services
|
4
|
- Many developers have found they are 5-10 times more productive
integrating independently developed Java components than C or C++
components. Why?
- Improved portability eliminates the need to “port”
components to each new hardware or operating system
- Object-oriented abstractions reduce name collisions and other
interference between components
- Automatic garbage collection simplifies integration by eliminating need
to assign responsibility for reclaiming memory used by one component
but allocated by another
- Summary: components simply work “out of the box”
|
5
|
- Intel project: budgeted 30 days to complete prototype software
development, finished in first weekend!
- Calix customer experience report: Compared with C++, the PERC real-time
Java product increased developer productivity by two fold, reduced code
size to one fifth.
- Nortel experience: Java developers are more productive and their code
more trouble-free than C++ developers.
- Trillium experience: Sells reusable network protocol stacks as C and C++
libraries. Each
“product sale” is bundled with an engineer who goes on-site
for several weeks to assist with the integration!
|
6
|
|
7
|
- The Real-Time Specification for Java (RTSJ)
- J2SE based: PERC, IBM, and Jamaica approach to soft and firm real-time
- Real-Time Core specification from J Consortium
- Open Group: Combining the best qualities of competing technologies in
establishing standards for safety- and mission-critical Java development
- Aonix is active participant in all ongoing real-time Java
standardization efforts
|
8
|
- Can be used for:
- hard real-time or soft real-time
- programming in the small, and in the large
- static systems and dynamic systems
- research and prototyping or product development
- Flexibility allows incredible generality
- Sometimes, a general purpose tool is not as easy to use as a specialized
tool
|
9
|
- Each RTSJ vendor is allowed and encouraged to differentiate its
implementation:
- Different schedulers
- Different libraries
- Different library semantics
- This hinders portability and
scalability
|
10
|
- Using conventional J2SE libraries and JVM with tightened semantics for
garbage collection, synchronization, and scheduling provides the
easiest, most portable, and most scalable development for large,
complex, and dynamic firm real-time applications
- But don’t try to filet a trout with a chopping blade
|
11
|
- Designed to support portable and scalable development of hard real-time,
high performance, and small footprint static systems for lower layers of
large software hierarchies
- Not recommended for large, complex, dynamic systems
- Integrates cleanly into a larger tool chest
- Safe, secure, high-performance integration of core components with firm
real-time Java components
|
12
|
- The High-Integrity Profile is designed to support development of DO-178B
certified (and similar) safety-critical systems
- Safe subset of the Real-Time Core Specification
- Isolated run-time does not allow mixing of firm real-time and
safety-critical components
- Leverages same development tools as real-time core: compilers,
debuggers, profilers, code coverage analyzers, etc.
|
13
|
- Driven by defense and commercial aerospace industries including:
- U.S. Air Force, U.S. Navy, NASA, Boeing, Lockheed Martin, Northrup
Grumman, Raytheon, …
- Includes participation of OOTiA committee members (e.g. John Chilenski,
Boeing)
- Builds on lessons learned by Ada 95 community
- U.S. Navy subcontract to Aonix for exploratory research and prototyping
|
14
|
- Have reached consensus on JSR for Safety Critical Java and general
technical approaches
- Combines best ideas of the RTSJ Expert Group and the J
Consortium’s Real-Time Core extensions
- Expect first draft of specification and prototype reference
implementation to be available Q1, 2005
- Sun has agreed to contribute reference implementation of
safety-critical Java standard
- Resulting specification will become ISO standard
- Sun has agreed to allow normative reference to existing Java
specifications
|
15
|
- Define standard “enhanced profiles” of the RTSJ to serve as
portable and scalable foundations for real-time Java development:
- One profile for safety-critical development
- One profile for hard real-time mission-critical development
- Likely enhancements include stack allocation of memory and interrupt
handling capabilities
- Next meeting in Boston, Mass on July 19-23
|
16
|
|
17
|
- Real-time garbage collection
- Real-time threading and synchronization
- Improved timing services
- VM Management API and PERC shell
|
18
|
- A PERC thread honors the priority specified by the developer
- Priorities are never automatically “aged”
- Every PERC synchronization lock implements priority inheritance
- All lock and wait queues are maintained in priority order
- Optional use of extended priority range (1-32)
- These semantics are offered across all targeted operating systems: ETS,
INTEGRITY, Linux, LynxOS, Nucleus, OSE, RTX, VxWorks, WinCE, Windows,
QNX
|
19
|
- Special Timer class implements same services as java.util.Timer with
improved semantics:
- Not affected by changes in system clock
- Uses system “up time”, measured in nanoseconds
- PercThread shadows java.lang.Thread; implements sleepUntil(),
waitUntil(), and cpuTime()
- PERC VM allows configuration of tick period and time slice duration
|
20
|
- A Java virtual machine represents considerable complexity
- Achieving optimal performance depends on understanding and controlling
what goes on “under the hood”
- The PERC VM Management API allows software to:
- Query and modify maximum number of heap regions
- Query and modify frequency and priority at which increments of garbage
collection are performed
- Determine which synchronization monitors are locked by which threads,
and which threads are waiting
- Determine how much time the VM is idle, and how much CPU time is
consumed at each priority level
- And various other services…
- The PERC shell provides a remote command-line interface to the
Management API services
|
21
|
- Key attributes of real-time GC:
- Preemptive
- Incremental
- Fully accurate
- Defragmenting
- Paced
- PERC GC is all of the above
|
22
|
|
23
|
- Incrementally copy objects from from-space into to-space
- Redirect memory accesses between Relocated and Reserved
|
24
|
|
25
|
- Objective: make sure the garbage collector gets enough CPU time, and no
more, to always stay ahead of the allocation needs of your application
- Technique:
- Determine maximum live-memory needs of application
- Measure the steady state allocation rate of application
- Measure total CPU time required to perform GC (bounded for the PERC VM)
- Perform schedulability analysis and configure the VM to dedicate
appropriate CPU time to GC
- Heuristic refinement: Monitor parameters continuously and make
configuration adjustments as necessary
|
26
|
|
27
|
- The J2SE standard for soft-real-time development provides the greatest
availability of:
- Off-the-shelf libraries (J2SE and 3rd parties)
- Developer tool support, including compilers, debuggers, run-time
profilers, code coverage analyzers
- General ease of development and maintenance due to portability, error
avoidance, encapsulation, and scalability
- Existing developer expertise, reference material, and training
resources
- Runs on traditional embedded architectures with a variety of popular
RTOS
- Timing precision to within approximately 1 ms
- Requires more memory and faster CPU than C
|
28
|
|
29
|
|
30
|
- There have been two ongoing standardization efforts to address this
need:
- The Java Community Process sponsored the Real-Time Specification for
Java as JSR-1
- Ben Brosgol, employed by Aonix, was a member of the expert group that
crafted this specification
- The J Consortium sponsored development of the “Real-Time
Core” specification
- I was the editor for this document as C.T.O. of NewMonics, which was
acquired by Aonix in July 2003
- Brian Dobbing and Marc Richard-Foy, employed by Aonix, were the
editors of the J Consortium’s High-Integrity Profile, a subset
of the core specification targeted to safety-critical development
|
31
|
- There are no “standard” libraries for real-time services
(e.g. multi-threading, synchronization, interrupt handling, device I/O)
- Time and effort is required to figure out the services of each RTOS
(documentation is often lacking so this usually requires trial and
error)
- Imprecise ANSI definition of “volatile”. Time and effort is required to
figure out each compiler.
- Will instructions be reordered?
When will store operations propagate to other processors?
Documentation may be poor.
Testing inconclusive: is behavior by design or coincidence?
- Poor abstraction and encapsulation fail to isolate concerns between
teams of developers
- No private variables, limited name spaces, lack of object orientation
limits code reuse
- Lesser evils: unknown type sizes, pointer manipulation and memory
corruption, C++ compiler differences
|
32
|
- Moving to a different RTOS, C compiler, or different hardware
architecture with the same C compiler and RTOS may break assumptions of
the original code
- Assumptions are rarely documented
- Requires extensive code review and comprehensive testing
- Porting/integration effort requires changes to source code
- Assembling independently developed components is likely to violate
integrity of certain components
- Variable naming collisions
- Race conditions may result from platform differences
|
33
|
- We characterize hard real-time as provable compliance with deadlines
- Though not specifically a “hard real-time issue”, market
requirements also demand high performance and small footprint
- Compliance proofs depend on static properties
- Pragmatic tradeoff: no automatic garbage collection
- More difficult development in absence of garbage collection
- Simpler run-time environment facilitates proof of program
characteristics, including compliance with deadlines
- Traditional “standard” libraries are not available because
they depend on automatic garbage collection
- We intend establish a new set of portable standard libraries to serve
the needs of this domain
|
34
|
- Will a hard real-time version of Java offer any meaningful benefits to
developers of hard real-time mission- and safety-critical code?
|
35
|
- Many experiments have concluded that Java developers are at least twice
as productive as C or C++ developers. Why?
- Stronger type checking reduces programmer errors
- Object-oriented encapsulation reduces interference between
independently developed components
- Forced exception handling reduces programmer errors
- Automatic garbage collection simplifies memory management and reduces
programmer errors
- Simpler language reduces programmer misunderstandings
- Improved portability allows programmers to master the language, rather
than mastering particular tool chains and RTOS services
|
36
|
- Many developers have found they are 5-10 times more productive
integrating independently developed Java components than C or C++
components. Why?
- Improved portability eliminates the need to “port”
components to each new hardware or operating system
- Object-oriented abstractions reduce name collisions and other
interference between components
- Automatic garbage collection simplifies integration by eliminating need
to assign responsibility for reclaiming memory used by one component
but allocated by another
- Summary: components simply work “out of the box”
|
37
|
- Compared to traditional development of hard real-time software using the
C language, can a hard real-time mission-critical Java deliver
2-fold/10-fold productivity improvement?
- Yes. But only if a hard
real-time mission-critical Java standard provides:
- Portable set of standard libraries
- Strong type checking and composable object-oriented encapsulation
- Portable byte-code representation of independently developed
components
- Safe logical partitioning between hard real-time and soft real-time
components to make available shared access to all of the services of
the soft real-time environment
|
38
|
- Boeing survey response:
- Mission-critical computing requires high performance, small memory
footprint, strong encapsulation and separation of concerns, high
reliability, good portability and scalability. The RTSJ addresses only the real-time
requirements.
- Nortel survey response:
- Having developed a large fiber-optic switch application comprised of 1
million lines of PERC and 4 million lines of C: “We prefer a fully Java or
a fully C/C++ solution. The
mixed/hybrid environment is very difficult and awkward for us.”
- Thales Avionics survey response:
- Java provides productivity benefits of 2 fold for development, 5-10
fold for maintenance and integration. Mission-critical software is
partitioned as two layers, with greatest complexity assigned to
higher-layer application software.
- European Space Agency response:
- Performance and footprint of Java are ok for ground segment
projects. But we need
harder real time, stronger encapsulation, and better reliability.
- Raytheon DD(X) team member:
- For most of our real-time software requirements, “if you have
real-time garbage collection, you don’t need the RTSJ.”
|
39
|
- This particular study focuses on integration of multiple software layers
in mission-critical systems:
- Real-time application layer, and
- System services layer includes device drivers, protocol stacks, some
hard real-time constraints, demanding performance and footprint
requirements
- This study only looks at issues pertaining to the interface between the
two domains
- Presented at Java Technology for Real-Time and Embedded Systems,
Catania, Italy, November, 2003
|
40
|
- JNI: The Java Native Interface, as defined by the Java Community Process
- Provides a “somewhat safe” way to combine C code (for hard
real-time processing) with Java code (for soft real-time processing)
- Full RTSJ: The Real-Time Specification for Java, as defined by the Java
Community Process
- Defines changes to the JVM which enable specially constructed threads
to achieve hard real-time determinism
- JRTK Subset of RTSJ (designed by Aonix):
- Defines a high-performance, hard-real-time Java-like run-time
environment that runs in concert with a JVM
|
41
|
- Zero-Copy Network Stack
- HRT thread: examines certain fields of packet and forwards 1 of 17 for
further processing by SRT thread, then processes entire payload
- SRT thread: examines and manipulates certain header information
associated with forwarded packets
- Streaming Data Recorder
- HRT thread: sums the integers in a packet buffer and sleeps 100
microseconds
- SRT thread: randomly generates values to be stored into the buffer and
hands buffer to HRT for processing
|
42
|
- Zero-copy Network Stack
- Streaming Data Recorder
|
43
|
- Fewer programmer concerns
- Less code to write and maintain
- Composability and object-oriented abstraction
- Protect low-level software
- Protect high-level software
- Run-time overhead of interface
- Run-time overhead of executing components
|
44
|
- Java programmers declare certain methods to be “native”
- Method is implemented in C code, using special macros and functions to
access shared Java objects
- Mechanisms are available to “pin” certain Java objects so
the native methods can directly access Java data using C pointer
semantics
- Native threads can “attach” to the JVM in order to invoke
Java methods and/or access shared Java objects
|
45
|
- Since it serves as “glue” between the JVM and the OS, JNI
code manifests many JVM and OS implementation dependencies
- Green threads vs. RTOS threads
- Object copying at interface or not
- RTOS priorities, RTOS services, Synchronization, etc.
- JNI code may compromise JVM integrity
- Native methods live outside the OO paradigm:
- May fail to unlock locks, fail to propagate exceptions, etc.
- Performance of the interface is expensive, requiring a certain amount of
marshalling
- C code runs sub-optimal because of object sharing protocols
- JVM threads run sub-optimal because of
coordination and synchronization protocols
|
46
|
- Refines JVM specification to require all threads to honor fixed
priorities and provide priority inversion avoidance
- Supplements standard APIs to provide RealtimeThread and
NoHeapRealtimeThread
- Adds wait-free queues to pass information between NoHeapRealtimeThread,
RealtimeThread, and java.lang.Thread
- Adds ImmortalMemory and ScopedMemory to support memory allocation within
real-time threads
|
47
|
- Understanding resource contention between RTSJ hard real-time components
and firm real-time components requires detailed understanding of RTSJ
implementation choices (not necessarily documented)
- Care must be taken to properly manage immortal buffers shared between
hard and soft real-time without using direct synchronization
- Absence of synchronization not enforced statically or dynamically
- Wait-free queues require information copying and/or dynamic buffer
management and design of ad hoc throttling techniques
- Performance penalties: NoHeapRealtimeThread implements read and write
barriers, RealtimeThread implements different write barrier, to enforce
“isolation” strategy
|
48
|
- Fewer programmer concerns
- Less code to write and maintain
- Composability and object-oriented abstraction
- Protect low-level software
- Protect high-level software
- Run-time overhead of interface
- Run-time overhead of executing components
|
49
|
|
50
|
|
51
|
|
52
|
|
53
|
|
54
|
- small-interp – Just enough core classes to load and interpret the
rest. -lazy-resolve option avoids linking dependencies.
- fast-interp – small-interp with AOT-compiled loader for faster
startup.
- small-jit – Core classes to load and JIT-compile the rest.
–lazy-resolve avoids dependencies. Loader and JIT compiler are
AOT-compiled.
- fast-jit – small-jit plus all standard JDK 1.3 classes. Everything
is AOT compiled.
|
55
|
|
56
|
|
57
|
- Run-Time Safety Checks
- Null pointer checking
- Array index checking
- Stack size checking and auto-resize
- Java and OO Language Features
- Synchronization, Exceptions
- Virtual method table-based indirection to method calls
- Automated Memory Management
- Heap-based object allocation
- Automatic garbage collection
|
58
|
- Firm Real Time Support
- Preemptible, incremental, defragmenting, type-accurate garbage
collector
- Preemption points for full scheduling control, hard priorities, and
priority inheritance
- One-time JIT compilation
|
59
|
|
60
|
|
61
|
|
62
|
- “Think Big. Think Bold.”
- Optera Connect HDX optical cross connect
- Successor to Nortel’s extremely successful OC192 product line
- Scalable to tens of terabits
- Needed a new software platform
- Software architecture needs to survive for ten years
- Large software team with a mixture of Object-Oriented and C
|
63
|
- The choice of Java over C++
- Previous products used mix of C and C++
- C for hard real-time and high-performance mission-critical and
real-time
- C++ wherever OOD is needed/beneficial
- Dislikes about C++
- Memory management, leaks, store tramplers
- “Big language” requires high level of training. Lots of
experts available, but “everyone needs to be an expert”.
- Unsafe for large software teams
- Why Java?
- Clean, safe, OO language
- Easy to read/write and learn
- New language, but reaching maturity
- Rich libraries
- Wealth of training available: books, web, courses
- Attractor to employees:
- Universities use Java extensively: New graduates know it
- Many Dinosaurs want to learn something new
|
64
|
- One-year pre-sales evaluation of PERC, J9, Jeode, Chai
- Deployed system has 1 million lines of PERC, 4 million lines of C
“We selected Java because we needed faster development,
increased robustness and improved portability. Aonix PERC product was
the only Java virtual machine to offer us the Ahead-Of-Time (AOT)
compilation and control over garbage collection. These features were
required so our software with hard real-time requirements, such as the
SONET Automatic Protection Switching (APS) engine, could exist
harmoniously with the Java-based card management software.”
Andy Thomas
Future Product Concepts
|
65
|
- Java developers are more productive than C++ developers, and Java code
is more reliable
- Unanticipated benefits:
- Code developed for first product was easily repurposed to another
product
- Evolving requirements required radical redesign half-way through
product development.
Object-oriented Java code was easily restructured.
- Next product will use more Java
- But Java not able to meet all of more stringent performance and
footprint requirements of control plane
|
66
|
- In-vehicle computers provide regulatory reports (driver logs, fuel tax
accounting)
- Maintain maintenance records for vehicle
- Continuous communication with central office (driver monitoring,
dispatch and route planning)
- Subscription pricing of enhanced services
|
67
|
|
68
|
- Asset Tracking
- Fuel Tax
- Operation Profile
- Diagnostic Warnings
- Email Select
- Daily Mileage
- DOT Logs
|
69
|
|
70
|
- Real-time GC
- Deterministic, Accurate, Incremental, Paced, Defragmenting
- Garbage collection Control API
- Embedded Target Support
- Static linking
- Visibility through Shell tool and VM APIs
- Native method invocation via PNI/JNI
- Interfaces with standard debuggers
|
71
|
- Java benefits realized:
- Increased functionality
- Portability: now running on 3 different platforms (Qualcomm, Symbol,
Proprietary)
- In-the-field bug fixes
- Subscription pricing of enhanced services
|
72
|
- Telecommunications: Alcatel, Calix, Inkra, Nortel, P-Cube,
Rohde-Schwarz, Turin
- General-purpose HMI controller for factory automation successfully
deployed (Digital Electronics)
- Commercially deployed in-vehicle computers for long-haul trucking
network (XataNet 2.0)
- Power plant automation under Beta test
- Semiconductor manufacturing under development
- Ongoing interaction with NASA JPL (MDS System), Boeing (Future Combat
Systems), Raytheon (DD(X) System), and U.S. Navy (Open Architecture
Computing Environment)
- Various other projects under non-disclosure agreements
|
73
|
|
74
|
- Embedded Java will eventually replace the large majority of C++ code and
much of the C code typical of today’s embedded systems
- The transition is evolutionary: C, C++, and Java work well together
- Aonix is ready to help you begin the transition today
- Aonix real-time Java products have already been proven in the
mission-critical commercial sector
|