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

GenerateCminTmax

MaxProcessorsMinProcessors

Issues

MaxProcessorsdepends on maximum number of threads in applicationMinProcessordepends on utiliation, and degree of paralle lism required

Ideally we don’t want to know the target processor. Hence the component threads’Cs must be budgets not WCETs

Global optimization problem

Portability of execution times

Even if actual WCET are known,the feasibility analysis is pessimistic as we do not know the scheduling regime on the platform

Threads

RTSJComponent

Offline Tool

Slide 19 (of 24)

Application Contract Analysis

GenerateCminTmax

MaxProcessorsMinProcessors

Either: given current contract and new application is system still feasibleOr: generate parameters and negotiate new contract

Global optimization problem

Increase in pessimism

Components

RTSJApplication

Offline/Online Tool

Slide 20 (of 24)

Multiprocessor PikeOS Schedulling

Slide 21 (of 24)

System-level PikeOS Analysis

CminTmaxMaxProcessorsMinProcessors

Application GeneratePikeOSscheduling

windows

Issues

Global optimization problemTotal System

Offline Tool

ConfigurationInformation

Slide 22 (of 24)

RTSJ-Level Analysis

CTO

Scheduling Windows

PriorityScheduler

Threads

RTSJComponent

Reservation

Slide 23 (of 24)

Summary of Concepts

Execution-TimeServer

Thread

External Contract

Reservation

Scheduling Window

Processor

*

1

* *

*

1

1

*

**

*

1

*

*

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