The Real-Time Specification for Java is now about two years old. It has been implemented, formed the basis for research and used in serious applications. Some strengths and weaknesses are becoming clear. This paper reviews the current status of the specification, outlines the challenges ahead and discusses areas where there is likely to be future design work

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

The Java language provides many benefits to application developers, including memory access safety, platform portability, and very high levels of productivity. However, some of the very Java language features that bring these benefits, such as the garbage collector, have also made it difficult or impossible to create applications with bounded response time characteristics. Implementations of the real-time specification for Java (RTSJ) are now available that have proven to be capable of supporting all aspects of real-time systems. This paper discusses the principal concepts underlying the RTSJ, use of the RTSJ's features in real-time applications, the most critical considerations that must be addressed by RTSJ-compliant Java virtual machine implementers, and two example RTSJ-compliant application designs that can fully utilize the RTSJ to portably support their performance requirements.

Abstract Elmwood is an object‐oriented, multiprocessor operating system designed and implemented during a graduate seminar. It consists of a minimal kernel and a collection of user‐implemented services. The kernel provides two major abstractions:objects, which consist of code and data, and processes, which represent asynchronous activity. Objects, like programs, are passive. To operate on an abstraction or to request a service, processes invoke anentry proceduredefined by the corresponding object. Objects implement their own protection and synchronization policies using minimal kernel mechanisms. We describe the Elmwood kernel interface, an implementation on the BBN Butterfly parallel processor, and our experiences in developing a multiprocessor operating system under rigid time constraints. These experiences illustrate several general lessons regarding kernel design and trade‐offs for implementation expedience.

A parallel file system called Bridge that distributes each file across multiple storage devices and processors has been designed and prototyped. The approach is based on the notion of an interleaved file, in which consecutive logical blocks are assigned to different physical nodes. Naive programs are able to access files just as they would with a conventional file system, while more sophisticated programs can export pieces of their code to the processors managing the data, for optimum performance. Early analytical and experimental results indicate that Bridge will deliver good parallel speedup for configurations in excess of 32 nodes with disks. High performance is achieved by exporting the I/O-related portions of an application into the processors closest to the data. A pair of applications that illustrate this technology is presented. General issues in the design of algorithms for Bridge are discussed.>