Notizen
Bildschirmpräsentation
Gliederung
1
Architectures for
Mission-Critical Development with Java
  • Kelvin Nilsen, CTO
    June 9, 2004
2
Outline
  • Introduction and Motivation


  • Real-Time Java Standards
    • Overview
    • Firm Real-Time
    • Hard Real-Time


  • Some experience reports


3
Productivity benefits of Java
  • 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
Productivity benefits of Java
  • 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
Representative experience
  • 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
Real-Time Java Standards
7
State of Real-Time Java Standards
  • 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
RTSJ Represents a “Swiss-Army Knife” Approach
  • 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
RTSJ Differentiation
  • Each RTSJ vendor is allowed and encouraged to differentiate its implementation:
    • Different schedulers
    • Different libraries
    • Different library semantics
  • This hinders portability and
    scalability
10
Firm Real-Time J2SE
  • 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
Real-Time Core Specification from J Consortium
  • 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 J Consortium’s High-Integrity Profile
  • 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
Open Group Standardization of Safety and Mission Critical Java
  • 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
Open Group Time Table
  • 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
Open Group Directions
  • 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
Using Standard Java APIs
 for Firm Real-Time Java
17
The Portable J2SE Firm Real-Time Platform
  • Real-time garbage collection


  • Real-time threading and synchronization


  • Improved timing services


  • VM Management API and PERC shell


18
Tightened Threading Semantics
  • 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
Improved Timing Services
  • 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
VM Management API
  • 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
Real-Time GC
  • Key attributes of real-time GC:
    • Preemptive
    • Incremental
    • Fully accurate
    • Defragmenting
    • Paced
  • PERC GC is all of the above
22
Incremental Mark and Sweep GC
23
Fully Copying Garbage Collection
  • Incrementally copy objects from from-space into to-space
  • Redirect memory accesses between Relocated and Reserved
24
Mostly Stationary Garbage Collection
25
How to Pace Garbage Collection
  • 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
Trace of Garbage Collection Pacing
27
Summary re: Firm Real-Time Java
  • 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
PERC Development Environment
29
Standardization of Hard Real-Time Java
30
Can Java Technologies Serve Hard Real-Time Community?
  • 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
Why is hard real-time C development hard?
  • 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
Difficulties of hard real-time C integration
  • 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
Applying Java benefits to hard real-time
  • 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..."
  • Will a hard real-time version of Java offer any meaningful benefits to developers of hard real-time mission- and safety-critical code?
35
Review: Productivity benefits of Java
  • 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
Review: Productivity benefits of Java
  • 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
Applying Java benefits to hard real-time
  • 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
RTSJ is only part of the solution
  • 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
U.S. Navy Sponsored Study
  • 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
Look at Three Available Techniques
  • 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
Two Experiments
  • 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
Empirical Analysis
  • Zero-copy Network Stack





  • Streaming Data Recorder
43
Interface Quality Evaluation Criteria
  • 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
JNI Overview
  • 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
Issues with the JNI Protocol
  • 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
RTSJ Overview
  • 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
Issues with the RTSJ
  • 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
Summary of Initial Analysis
  • 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
Logical Partitioning of Memory
50
Safe, Efficient Sharing and Synchronization
51
The PERC Product
52
PERC Development Flow
53
Execution and Loading Tradeoffs
54
PERC Default Executables
  • 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
Default Executable Sizes PERC 4.0*
56
Sieve Results
57
Comparative Performance: Java vs. C
  • 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
Comparative Performance: PERC vs. Java
  • 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
PERC Development Environment
60
Transitioning to Safety-Critical Java
61
Commercial Experience
62
Nortel Fiber-Optic Switch Design Issues
  • “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
Why Nortel Chose Java over C++
  • 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
Nortel Pre-Sales Evaluation
  • 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
Nortel Findings
  • 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
Xata Long-Haul Commercial Trucking
  • 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
XataNetä System
68
XataNetä Applications
  • Asset Tracking
  • Fuel Tax
  • Operation Profile
  • Diagnostic Warnings
  • Email Select
  • Daily Mileage
  • DOT Logs


69
Xata System Components
70
Relevant Benefits of PERCä
  • 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
Xata long-haul commercial trucking
  • 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
Representative Experience
  • 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
Product Mix
74
Summary
  • 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