Transcript A Little Bit of Real

A Little Bit of Real-Time Java
Nels Beckman
SSSG
November 7th, 2005
Introduction
1. Design choices, trade-offs and motivations in
the Real-Time Specification for Java
2. Effects of these choices
3. Possible high-level research directions
11/7/05
Nels Beckman, SSSG
2
Outline
•
•
•
•
•
•
Introduction
RTSJ Background
Seven Enhanced Areas
New Memory Model
Comments on RTSJ
Conclusion
11/7/05
Nels Beckman, SSSG
3
RTSJ Background
Briefly: What is Real-Time?
• “A real-time system is one that has performance
deadlines on its computations and actions n”
• Real-time software is
– Event-driven, Time-Driven, or both
– Often embedded
– Often safety-critical
• Example:
– Flow-Rate Control System3
11/7/05
Nels Beckman, SSSG
4
RTSJ Background
What is the RTSJ?
• Standard Java is not appropriate for RT
• It provides additions to Java, so it can be used in
the development of real-time systems
• Specifically
– Extensions to JVM Specification
– Creation of real-time API
11/7/05
Nels Beckman, SSSG
5
RTSJ Background
Why Real-Time Java?
• Java = Slow?
• Real-Time = Fast?
• Real-time applications typically are a mixture of
real-time and non real-time threads1
– So what about the “rest” of the code in a RT
application?
11/7/05
Nels Beckman, SSSG
6
RTSJ Background
History of the RTSJ
• Core requirements originate from NIST workshop
• The first Java Specification Request in the Java
Community Process (1999)
• Proposed by IBM
• The Real-Time Java Experts Group was chartered with
leading its creation
• Members of Note
– Greg Bollella
– Ben Brosgol
– James Gosling
11/7/05
Nels Beckman, SSSG
7
RTSJ Background
RTJEG’s Guiding
1. Applicability to
Particular Java
Environments
2. Backward Compatibility
3. Write once, Run
Anywhere
4. Current
Practice/Advanced
Features
11/7/05
2
Principles
5. Predictable Execution
6. No syntactic extension
7. Allow Variation in
Implementation
Decisions
Nels Beckman, SSSG
8
Outline
•
•
•
•
•
•
Introduction
RTSJ Background
Seven Enhanced Areas
New Memory Model
Comments on RTSJ
Conclusion
11/7/05
Nels Beckman, SSSG
9
7 Enhanced Areas
1. Thread Scheduling & Dispatching
• Original Java Spec: “…threads with higher priority
are generally executed in preference to threads with lower
priority…”
• RTSJ
– Requires at least a fixed priority, preemptive
scheduler.
– Defines classes for execution eligibility and schedule
feasibility.
11/7/05
Nels Beckman, SSSG
10
7 Enhanced Areas
2. Synchronization
• RTSJ adds:
– Priority queuing on synchronized blocks
– Required priority inversion avoidance
– Wait free queues
11/7/05
Nels Beckman, SSSG
11
7 Enhanced Areas
3. Asynchronous Event Handling
• Real-time applications typically must respond to
events in the real world and in other parts of the
application
• RTSJ Adds:
– Asynchronous events
– Asynchronous event handlers
• Handlers are runnable, and thus are associated
with deadline information, etc.
• Events include periodic and one shot timers
11/7/05
Nels Beckman, SSSG
12
7 Enhanced Areas
4. Asynch. Transfer of Control
• Occasionally necessary to transfer control
immediately and permanently
• RTSJ adds ATC
– Code declares itself interruptible (think ‘throws’).
– Asynchronous events can enact a transfer of control
to a predetermined point.
11/7/05
Nels Beckman, SSSG
13
7 Enhanced Areas
5. Asynch. Thread Termination
• A more specific case of asynchronous transfer
of control
• Java
– thread.stop(),thread.destroy()
– Deprecated, can lead to deadlock
• RTSJ
– thread.interrupt()
– Thread can catch interruption and clean up
11/7/05
Nels Beckman, SSSG
14
7 Enhanced Areas
6. Physical Memory Access
• RTSJ Adds:
– Direct access to physical memory
– You specify the address range
– Individual bytes, ints, longs, etc. can be accessed
11/7/05
Nels Beckman, SSSG
15
7 Enhanced Areas
7. Memory Management
• Java has garbage collection
• Garbage collection is certainly easy to use
• But is it real-time appropriate?
• State-of-the-art in real-time garbage collection4
– ~50% cpu overhead
– 1.5X memory overhead.
11/7/05
Nels Beckman, SSSG
16
Memory Management
So No Heap? Now What?
• RTSJ has multiple thread types
– Thread
– RealtimeThread
– NoHeapRealtimeThread
11/7/05
Nels Beckman, SSSG
17
Memory Management
Three Types of Memory
• Heap memory
– Standard Java Heap
• Immortal memory
– Immortal memory, exists for the life of the
application
• Scoped Memory
– A way to reclaim memory without a garbage
collector
11/7/05
Nels Beckman, SSSG
18
Memory Management
Scoped Memory
•
•
Scopes have fixed lifetimes
Lifetime starts here:
– scopedMemArea.enter() { … }
•
11/7/05
Lifetime ends:
Nels Beckman, SSSG
19
Memory Management
Scoped Memory
•
•
11/7/05
All calls to new inside a scope, create an object
inside of that scope
When the scope’s lifetime ends, all objects
within are destroyed
Nels Beckman, SSSG
20
Memory Management
Scope Nesting
•
Scopes can be nested
– scopedMemArea.enter() {
...
anotherScope.enter() {
}
...
}
11/7/05
Nels Beckman, SSSG
21
Memory Management
Memory Safety
• Must ensure
heap
– No dangling pointers
– Objects can’t refer to
shorter lived objects
• An RTSJ must ensure
this with run-time checks
11/7/05
Nels Beckman, SSSG
immortal
parent
child
22
Memory Management
Common Scoped Memory Patterns
• Scoped Loops
– Used when temporary information created at each
iteration of a loop
– eg.)
void mainLoop() {
while(true) {
...
}}
11/7/05
Nels Beckman, SSSG
23
Memory Management
Common Scoped Memory Patterns
• Scoped Loops
– Used when temporary information created at each iteration
of a loop
– Now:
Class Runner implements Runnable {
void run() {
... }}
void runLoop() {
memory = new LTMemory( size,max );
myRunner = new Runner();
while(true) memory.enter( myRunner );}
11/7/05
Nels Beckman, SSSG
24
Memory Management
Common Scoped Memory Patterns
• Scoped Methods
– Similar to scoped loops
– Body of method runs in memory scope
• Caveat:
– State must be saved in a parent scope
– Must take explicit care to do this
11/7/05
Nels Beckman, SSSG
25
Memory Management
A Programmer’s Nightmare?
• Programming mistakes lead to run-time errors
• StateObject state;
void run() {
state = new StateObject();
Runner r =new Runner(state);
nestedScope.enter(r);
//Here is ‘state’ in my scope?
//Is it in sub scope?
}
11/7/05
Nels Beckman, SSSG
26
Memory Management
What’s the Problem Here?
1. The particular scope in which a given object
resides in is implicit
2. The nesting relationship of scopes is implicit
3. Nesting relationship can change at run-time
•
11/7/05
The RTSJ has some capability here, but still
requires run-time comparisons
Nels Beckman, SSSG
27
Memory Management
Some Proposed Techniques
1. Scoped Types for Real-Time Java, Vitek et. al.
2. Ownership-types for Safe Region-Based
Memory Management in Real-Time Java,
Boypati, et al.
3. Cyclone: A Safe Dialect of C
•
11/7/05
All proposed techniques integrate memory
location into the type system.
Nels Beckman, SSSG
28
Memory Management
Sharing Data Between Threads
• More Funny Behavior
• Portals provide placeholder for shared data
• But scopes are deleted when no threads occupy
it!
– This can make sharing data hard!
11/7/05
Nels Beckman, SSSG
29
Memory Management
Sharing Data Between Threads
finalize()
11/7/05
Nels Beckman, SSSG
30
Memory Management
Sharing Data Between Threads
• So we get hacks!
• The Wedge-Thread pattern
– Sleeps a thread inside the memory scope in order to
keep it alive
– Then receiver thread wakes sleeping thread up again
• This is Backhanded Memory Management!
11/7/05
Nels Beckman, SSSG
31
RTSJ Commentary
Comments on the RTSJ
• First: Designing frameworks and extensions is
hard
– External constraints:
• eg.) Syntax should stay the same to preserve tool
compatibility
– Finding balance between users’ previous experience,
and what the new domain mandates
• eg.) We would like to use garbage collection, but
performance is unacceptable
11/7/05
Nels Beckman, SSSG
32
RTSJ Commentary
Comments on the RTSJ
• Tendencies are hard to break?
– Java tends to push errors towards run-time discovery
– But this philosophy may be counter to Real-Time
• eg.) When my real-time app is running, what do I do with
a MemoryAccessError? What about a
ScopeCycleException?
• Designers of real-time applications don’t like to
be surprised!
11/7/05
Nels Beckman, SSSG
33
RTSJ Commentary
Comments on the RTSJ
• Would real-time developers use the RTSJ?
• I say it depends on the task
• In safety critical systems, for the most part,
memory is not dynamically allocated.
• But realistically, RTSJ seems targeted at soft realtime, or at least non critical.
11/7/05
Nels Beckman, SSSG
34
RTSJ Commentary
Proposed Research Directions
• Soft real-time is an interesting problem space
• Can currently ‘interactive’ software, be given
some real-time guarantees?
– Appliances, media decoders, etc.
• Can we make it cheaper to do?
• Hopefully, type systems and annotations may
provide the answer!
11/7/05
Nels Beckman, SSSG
35
RTSJ Commentary
Proposed Research Directions
• Currently, reading up on type systems that help
us to bound resource usage
11/7/05
Nels Beckman, SSSG
36
Conclusion:
• Thanks for your attention
• I hoped you learned something about RealTime/RTSJ!
11/7/05
Nels Beckman, SSSG
37
References
1.
2.
3.
4.
5.
11/7/05
Bollella, G., Canham, T., Carson, V., Champlin, V., Dvorak, D., Giovannoni,
B., Indictor, M., Meyer, K., Murray, A., and Reinholtz, K. 2003.
Programming with non-heap memory in the real time specification for
Java. In Companion of the 18th Annual ACM SIGPLAN Conference on ObjectOriented Programming, Systems, Languages, and Applications (Anaheim, CA,
USA, October 26 - 30, 2003). OOPSLA '03. ACM Press, New York, NY.
Bollella, G.; Gosling, J. The real-time specification for Java Computer,
Vol.33, Iss.6, Jun 2000 Pages:47-54
Douglass, B. P. 1999 Doing hard time: developing real-time systems with UML,
objects, frameworks, and patterns. Addison-Wesley Longman Publishing Co.,
Inc.
Tian Zhao, James Noble, Jan Vitek. "Scoped Types for Real-Time Java,"
rtss, pp. 241-251, 25th IEEE International Real-Time Systems Symposium
(RTSS'04), 2004.
Pizlo F, Fox JM, Holmes D, Vitek J. “Real-Time Java Scoped Memory:
Design Patterns and Semantics.”
Nels Beckman, SSSG
38