Enhancing the Platform Independence of the Real-Time Specification for Java Andy Wellings, Yang Chang and Tom Richardson University of York

Slide 2 (of 24) Agenda Motivation Contracts and Resource Partitioning Resource Contracts and the RTSJ The JEOPARD Project

Slide 3 (of 24) Motivation I The RTSJ supports an environment that facilitates on-line feasibility analysis An RTSJ program is normally run on an execution platform that might be shared with other applications In order for the RTSJ scheduler to provide guarantees, it must negotiate (or be given) a contract with the underlying OS which guarantees a minimum level of access to the physical resources of the platform Operating systems often provide this support via reservation- based scheduling techniques

Slide 4 (of 24) Motivation II Applications with different criticality and timing requirements need to dynamically share the same hardware platform Reserving resources for each application is key to satisfying applications' dramatically different requirements It is also important to reserve resources for application components

Slide 5 (of 24) Motivation III We want to produce component-based real- time systems

Slide 6 (of 24) Resource Partitioning In general there are two main approaches to partitioning the processor resource:  using execution-time servers and  via time-slicing

Slide 7 (of 24) Execution-Time Servers Initially introduced in order to ensure that servicing soft aperiodic activities would not impact on the hard periodic and sporadic activities (termed aperiodic servers or periodic servers) Servers are an accounting mechanism; they need not have physically processes or threads at run-time All the approaches have the notion of a capacity and a replenishment period A key distinguishing characteristics between them is the extent to which they preserve their capacity if there is no current aperiodic activity (bandwidth preserving)

Slide 8 (of 24) Execution-Time Servers Servers have also been used to implement composable real- time embedded systems For composition, the key requirement is that the server must be guaranteed its budget each period; i.e it must be possible for the server to consume all its budget on each release To support aperiodic execution, it is sufficient that the aperiodic server consumes no more than its budget each period  Hence the budget can be greater than can be guaranteed

Slide 9 (of 24) Time Slicing Execution-time servers  Not deterministic enough to be used for the purposes of separating applications with different criticality and stopping fault propagation Alternative way of preserving resources is via time slicing  widely used in many industrial application areas, especially in avionic systems

Slide 10 (of 24) Partitioning In a uniprocessor system time slicing system  applications are often scheduled on a fixed, cyclic basis,  implemented by maintaining a fixed length major time frame composed of fixed scheduling windows and repeating such a scheduling scheme Such an approach is often called partitioning  Each partition (application) is allocated to one or more scheduling windows in the major time frame  Different partitions can never share a scheduling window A scheduling window can be defined by its offset from the beginning of its major time frame and its length  Individual scheduling windows do not overlap but gaps between them are allowed

Slide 11 (of 24) Example Partition

Slide 12 (of 24) Resource contracts and the RTSJ Several approaches that could be taken to  Support directly the JSR-284 Resource Management API  However, this is a heavy-weight mechanism, and the RTSJ already has a framework for monitoring the CPU resource  The alternative is to integrate into the RTSJ the real-time approaches previously considered  This can be done either via the execution-time server approach or the time slicing approach  The RTSJ already supports a form of execution-time servers via the ProcessingGroupParameter class

Slide 13 (of 24) Resource contracts and PGP ProcessingGroupParameter is primarily used to support aperiodic activities and allows the group to consume no more than its budget each period For composition and partitioning, what is required is to ensure that a processing group is guaranteed its budget each period

Slide 14 (of 24) Contracts External contract  The contract the real-time JVM has with the underlying OS that guarantees a certain quality of service. This contract is enforced by the OS.  It is visible to the RTSJ scheduler but may or may not be visible to the application Internal contract  The contract a component of the program has with the RTSJ scheduler that guarantees a certain quality of service from the real-time JVM.  This contract is enforced by the real-time JVM and is invisible to the OS – a form of PGP (called Execution-Time Server)

Slide 15 (of 24) Use Cases External and internal contracts pre- negotiated and statically allocated External contracts pre-negotiated and statically allocated. Internal contracts dynamically negotiated. All contracts dynamically negotiated

Slide 16 (of 24) The JEOPARD Project Strategic objective: to provide the tools for platform independent development of predictable systems that make use of SMP multicore platforms. Focus of this talk:  The overall model for constructing and guaranteeing components, applications and systems.  The implementation on top of a multicore/multiprocessor version of the PikeOS

Slide 17 (of 24) JEOPARD Context More than one application share the same multiprocessor platform  Each application has an external contract with the OS An application consists of separately developed (potentially) multi-threaded components  Each component has an internal contract with the RT-JVM A contract is specified as  Min C, Max T, Min Processors, Max Processors

Slide 18 (of 24) Component Contract Analysis

Slide 19 (of 24) Application Contract Analysis

Slide 20 (of 24) Multiprocessor PikeOS Schedulling

Slide 21 (of 24) System-level PikeOS Analysis

Slide 22 (of 24) RTSJ-Level Analysis

Slide 23 (of 24) Summary of Concepts

Slide 24 (of 24) Conclusions The RTSJ tries to continue Java ’ s platform independence Silent on many issues of on-line feasibility analysis Both external and internal contracts needed Internal at least needs to be standardised There is need for a better “ grouping ” mechanisms in RTSJ