Transcript Enhancing the Platform Independence of the Real-Time Specification for Java

Enhancing the Platform Independence of the
Real-Time Specification for Java
Andy Wellings, Yang Chang and Tom Richardson
University of York
Agenda

Motivation

Contracts and Resource Partitioning

Resource Contracts and the RTSJ

The JEOPARD Project
Slide 2 (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 reservationbased scheduling techniques
Slide 3 (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 4 (of 24)
Motivation III

We want to produce component-based realtime systems
Slide 5 (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 6 (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 7 (of 24)
Execution-Time Servers



Servers have also been used to implement composable realtime 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 8 (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 9 (of 24)
Partitioning

In a uniprocessor system time slicing system



Such an approach is often called partitioning



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
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 10 (of 24)
Example Partition
Slide 11 (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 12 (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 13 (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 14 (of 24)
Use Cases



External and internal contracts prenegotiated and statically allocated
External contracts pre-negotiated and
statically allocated. Internal contracts
dynamically negotiated.
All contracts dynamically negotiated
Slide 15 (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 16 (of 24)
JEOPARD Context

More than one application share the same
multiprocessor platform


An application consists of separately developed
(potentially) multi-threaded components


Each application has an external contract with the OS
Each component has an internal contract with the RT-JVM
A contract is specified as

Min C, Max T, Min Processors, Max Processors
Slide 17 (of 24)
Component Contract Analysis
Issues
Offline Tool
Threads
RTSJ
Component
Generate
Cmin
Tmax
MaxProcessors
MinProcessors
Global optimization problem
MaxProcessorsdepends on maximum
number of threads in application
MinProcessordepends on utiliation, and
degree of parallelism required
Portability of execution times
Ideally we don’t want to know the target
processor. Hence the component threads’Cs
must be budgets not WCETs
Even if actual WCET are known,
the feasibility analysis is
pessimistic as we do not know
the scheduling regime on the
platform
Slide 18 (of 24)
Application Contract Analysis
Offline/Online Tool
Components
Generate
Cmin
Tmax
MaxProcessors
MinProcessors
RTSJ
Application
Global optimization problem
Either: given current contract and new
application is system still feasible
Or: generate parameters and
negotiate new contract
Increase in pessimism
Slide 19 (of 24)
Multiprocessor PikeOS
Schedulling
Slide 20 (of 24)
System-level PikeOS Analysis
Offline Tool
Application
Cmin
Tmax
MaxProcessors
MinProcessors
Generate
PikeOSscheduling
windows
Issues
Total System
Global optimization problem
Slide 21 (of 24)
Configuration
Information
RTSJ-Level Analysis
C
T
O
PriorityScheduler
Scheduling Windows
Reservation
Threads
RTSJ
Component
Slide 22 (of 24)
Summary of Concepts
Execution-Time
Server
*
*
*
*
1
Reservation
*
*
1
*
Processor
*
External Contract
1
1
*
*
Scheduling Window
Slide 23 (of 24)
Thread
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
Slide 24 (of 24)