The Real-Time Specification for Java (RTSJ) was the first Java Community Process' Java Specification Request (JSR-1). The initial version of the specification was produced in June 2000 in parallel with a Reference Implementation. Inevitably, the completion of the RI showed us bugs and inconsistency. Many of these were been removed in the 1.0.1 version of the specification that was released in August 2004, and the 1.0.2 version of the specification that was released in July 2006 (see www.rtsj.org). However, minor releases such as these are limited to issues that can be construed as bug fixes or clarifications. As commercial products have appeared and user experienced has been accrued, some enhancements to the RTSJ have been requested. These enhancement requests form the basis for the scope of JSR 282. This short paper summarizes the progress that has been made.

Preface. Introduction. 1. Landscape. Java Technology and Real Time. Real-Time Programming Requirements. Java and Embedded Real Time. Definition of Real Time. Precision of Measurement. Consistency. Utility Function Curve. Java's Problem Domain. Real-Time Java's Problem Domain. Summary. 2. Architecture of the Java Virtual Machine. Write Once, Run Anywhere: Maybe. JVM Components. Class Loading. Bytecode Interpreter. Security Manager. Garbage Collector. Thread Management. Input/Output. Graphics. Interpreter Implementation. Standard Interpreter. Optimized Interpreter. JIT. Snippets. Compilation to Independent Process. Native Methods. Compilation to a Native Method. Compilation to the JIT Interface. 3. Hardware Architecture. Worst-Case Execution of One Instruction. Worst-Case Scenario. Practical Measures. Management of Troublesome Hardware. Managing Demand Paging. Managing DMA. Managing Cache. Managing Address Translation Cache. Managing Interrupts. Effects on the JVM. 4. Garbage Collection. Reference Counting. Basic Garbage Collection. Mark and Sweep. Defragmentation. Copying Collectors. Incremental Collection. Incremental Garbage Collection in Practice. Generational Garbage Collection. Intergenerational References. Large Object Store. Real-Time Issues. 5. Priority Scheduling. Scheduling Terms. Execution Sequences. Preemption. The Seductive Charm of Nonpreemptive Scheduling. Fixed versus Dynamic Priority. Priority Inversion. Why 32 Priorities? Problems with Priority Scheduling. 6. Scheduling with Deadlines. Underlying Mechanism. Scope of the Scheduler. Some Systems. Earliest Deadline First (EDF). Least Laxity. Periodic Scheduling. Aperiodic Servers. Handling Overload. Timing Is Usually Probabilistic. 7. Rate Monotonic Analysis. Theorems. Liu and Layland's Theorem. A Graphical Approach. Lehoczky, Sha, and Ding's Theorem. Restrictions. Independent Tasks. Deadlines Equal to Periods. Multiprocessor Systems. 8. Introduction to the Real-Time Java Platform. A Brief History of Real-Time Java. Major Features of the Specification. Threads and Scheduling. Garbage Collection. Asynchronous Event Handlers. Asynchronous Transfer of Control. Memory Allocation. Memory Access. Implementation. RTSJ Hello World. 9. Closures. The Language Construct. Java Closures. Closure Structure. Closures in the RTSJ. Limitations of Closures. Readability. Local Variables. Constructors. Nesting. 10. High-Resolution Time. Resolution. The clock. HighResolutionTime Base Class. Absolute Time. Relative Time. Rational Time. 11. Async Events. Binding a Happening to an Event. Basic Async Event Operation. Async Events without Happenings. Time Triggering. Fault Triggering. Software Event Triggering. Implementation Discussion. 12. Real-Time Threads. Creation. Scheduling. Inversion Handling. Fixed Priority. Feasibility. Periodic Threads without Handlers. Feasibility Analysis. Periodic Threads with Handlers. Interactions with Normal Threads. Changing the Scheduler. 13. Non-Heap Memory. The Advantage of Non-Heap Memory. The Allocation Regimes. Rules. Mechanisms for Allocating Immortal Memory. Mechanisms for Allocating from Scoped Memory. Allocation Time. Creating Scoped Memory. Allocation Mechanisms. Finalizers. Using Nested Scoped Memory. The Scope Stack (Tree). The DAG. Practical Use of Nested Scopes. Every Nested Scope Involves Two Memory Areas. Pitfalls. Using executeInArea. Using Standard Classes. Using Shared Scoped Memory. The Scope Stack Revisited. Scope Portals. Fine Print. Quick Examples. 14. Non-Heap Access. Interaction with Scheduler. Rules. Samples. Final Remarks. Notes. 15. More Async Events. Async Events and the Scheduler. The createReleaseParameters Method. Bound Async Event Handlers. Async Event Handlers and Non-Heap Memory. No-Heap Event Handlers vs. No-Heap Threads. Scheduling. Minimum Interarrival Time. Async Event Handlers and Threads. Special Async Events. 16. Reusing Immortal Memory. Using Fixed-Object Allocators. Carrier Objects. Limitations. Recycling RT Threads. Recycling Async Event Handlers. 17. Asynchronous Transfer of Control. Thread Interrupt in Context. Asynchronous Interrupt Firing. The Timed Class. The interrupt Method. The fire Method. In Summary. Replacement Rules. Rules for Async Exception Propagation. Oblivious catch. Nonmatching doInterruptible. Matching doInterruptible. Internals. Application Handling for Asynchronous Interrupts. Noninterruptible Code. Special Issues for Synchronized blocks. Legacy Code. Use of ATC for Thread Termination. 18. Physical Memory. Physical and Virtual Memory. Physical Memory Manager. Memory Type. Removable Memory. Immortal Physical Memory. Scoped Physical Memory. 19. Raw Memory Access. Security. Peek and Poke. Get/Set Methods. Mapping. The RawMemoryFloatAccess Class. 20. Synchronization without Locking. Principles of Wait-Free Queues. Constructors. Common Methods. The Wait-Free Write Queue. Methods. Sharing the Wait-Free Queue. The Wait-Free Read Queue. The Extra Constructor. Methods. The Wait-Free Double-Ended Queue. Methods. No-Wait Queues and Memory. Implementation Notes. 21. Recommended Practice. Powerful and Easy-to-Use Features of the RTSJ. Real-Time Threads. Periodic Threads. Asynchronous Event Handlers. High-Resolution Time. Happenings. Very Powerful and Dangerous Features of the RTSJ. Simple. Leaky. Viral. Very Powerful and Finicky Features of the RTSJ. Scoped Memory. No-Heap Asynchronous Event Handlers. No-Heap Real-Time Threads. Asynchronously Interrupted Exceptions. Selection of Priorities. Index.

The Real-Time Specification for Java (RTSJ) was the first Java Community Process' Java Specification Request (JSR-1). The initial version of the specification was produced in June 2000 in parallel with a Reference Implementation. Inevitably, the completion of the RI showed us bugs and inconsistency. Many of these have been removed in the 1.0.1 version of the specification that was released in August 2004, and the 1.0.2 version of the specification that was released in July 2006 (see www.rtsj.org). However, minor releases such as these are limited to issues that can be construed as bug fixes or clarifications.As commercial products have appeared and user experienced has been accrued, the time is right to consider some of the simpler enhancements that have been requested. These enhancement requests form the basis of JSR 282. They include:1. Add waitForNextRelease() and release() methods to the RealtimeThread class so that real-time threads will be better able to handle aperiodic processing.2. Investigate a class, similar to the weak reference classes, that supports references between memory areas that would normally be forbidden by the RTSJ assignment rules.3. Relax the bi-directional reference rule for parameter objects.4. Add new methods in the Timed and Timer classes to more easily support both start relative to now and start relative to the original start time, for reset and reschedule.5. Add a form of Timed.reset() that resets the timeout for the current execution.6. Add new methods to query the state of Timers and real-time threads.7. Add a method to the Schedulable interface and processing group parameters, that will return the elapsed CPU time for that schedulable (if the implementation supports CPU time)8. Add an option for asynchronous event handlers that will cause the AEH's memory area to be entered each time the AEH invokes handleAsyncEvent().9. Consider a method that determines whether there is more than one reference to an object. (To better support recycling lists).10. Add a blocking factor value to ReleaseParameters to support better feasibility analysis.11. Review the current support for real-time garbage collectors, and expand it if necessary.12. Associate a scheduling eligibility value with asynchronous events.13. Permit all errors associated with exceeding RTSJ resource limits to fire asynchronous events (or alternatively, release asynchronous events event handlers). Currently some of them can only throw exceptions.14. Add new methods as necessary to consistently provide both a method that creates a returned object and one that takes a destination wherever those forms are appropriate.15. Update the documentation for the physical memory classes to improve their clarity. Make the minimum modifications to the semantics and APIs required to fix any problems that justify such changes.16. Update the semantics for cost enforcement to permit support of the invariant that a schedulable's CPU use in each period is bounded by the cost.17. Consider compatible modifications to the RTSJ that would make it easier to limit the use of immortal memory.18. Modify the specification as required to clarify any interaction with Java™ 5.19. Consider hierarchical processing group parameters.20. Consider improvements to the wait-free queue classes, or possibly new classes with similar services.21. Consider enhancements to the async event system to let events carry data.The talk will present the current status of these and other developments.

Modem real-time programming languages and operating systems provide support for monitoring the amount of CPU time a thread consumes. However, no system in widespread use fully integrates this monitoring with the scheduling facilities. The real-time specification for Java (RTSJ) provides an integrated approach to scheduling periodic threads and monitoring their CPU execution time. It supports a cost enforcement model whereby a periodic thread is suspended when it consumes more time than it requested. Version 1.0 of the RTSJ is under specified and it is difficult to understand the full model. This paper clarifies the position and defines the conditions under which a real-time thread is resumed. The model presented is the one that is fully defined in version 1.0.1 of the RTSJ. Unfortunately, version 1.0.1 of the specification will not have a general model for handling cost enforcement and deadline monitoring for all schedulable objects. This paper proposes extensions to the RTSJ that allow the cost enforcement model and deadline monitoring model to be consistently applied across all schedulable objects, and for it to be fully integrated with scheduling

From the Book: You can treat this book as two closely-related books. Chapters 1 through 7 are background that might help understand the RTSJ. The remainder of the book is about the RTSJ itself. If you already understand real-time scheduling, or you donUt care about scheduling and want to get directly to the code, you can start at Chapter 8 and read from that point on. Other than possibly skipping the first seven chapters, I do not recommend skipping around. Few of the chapters can stand by themselves. After youUve skimmed the book once, it can work as reference material, but I suggest that you start by reading the book sequentially. This book is intended to serve as part of a set comprising three elements: the RTSJ specification, the reference implementation, and this book. You can find the specification and the reference implementation through www.phptr.com/dibble or www.rtj.org. The preliminary RTSJ document is part of the Addison-Wesley Java Series. It is available in hard copy through your favorite book store. However, the preliminary RTSJ has been superseded by the final, version 1.0, version. At this time, the final specification is only available as downloadable PDF and HTML. The reference implementation is a complete and usable implementation of the RTSJ for Linux. Almost every example in this book was tested on the reference implementation. I have used the reference implementation on PCs running Red Hat Linux and TimeSys Linux, and it should work with other versions of X86 Linux as well, but the reference implementation relies on the underlying operating system for scheduling, so you will find that features like priority inversion avoidance will depend on the versionof Linux you use. The source code for the reference implementation is available. Some of it is descended from the Sun CVM. That is available under the Sun community source license. The parts of the reference implementation that are not related to Sun code are covered under a less restrictive open source license. Although the reference implementation is excellent for experimentation, it is not designed for commercial use. It does not take the care with performance or memory use that youUd expect from a commercial product. You can find links to important web sites, corrections and extensions to this book, and probably other useful things like source code at www.phptr.com/dibble

It is widely recognized that significant advances in computational power require some form of parallel processing. This has led to a range of proposals for multiprocessor architectures. It seems that traditional file access is one issue that has been deferred in the development of many of these new parallel machines and the software programming environments designed to make them usable. The project described in this paper is a first attempt to investigate the architectural considerations involved in providing a file system and its potential role for applications in the context of the BBN Butterfly multiprocessor. We have implemented a prototype called Bridge that distributes file data in an interleaved fashion over the secondary memories of multiple processor nodes. We discuss the design choices we have made, some preliminary experiences with the implementation, and opportunities this kind of file structure presents for algorithm design.