A Methodology and Tool Support for Generating Scheduled Native Code for Real-Time Java Applications

TL;DR: Current trends in industry are leading towards the use of Java as a programming language for implementing embedded and real-time applications, and the Java environment is indeed a very attractive development framework.

Abstract: Current trends in industry are leading towards the use of Java [5] as a programming language for implementing embedded and real-time applications. From the software engineering perspective, the Java environment is indeed a very attractive development framework. Object-oriented programming provides encapsulation of abstractions into objects that communicate through clearly defined interfaces. Dynamic loading eases the maintenance and improvement of complex applications with evolving requirements and functionality. Besides, Java provides built-in support for multi-threading.

Summary

1 Introduction

• Current trends in industry are leading towards the use of Java [5] as a programming language for implementing embedded and real-time applications.
• Among such work, the authors should mention the Real-Time Specification for Java [11], and the Real-Time Core Extension for the Java Platform [12], that provide support for real-time programming (timers, clocks, handlers, priorities, . . . ).
• The semantics proposed by the profile do not fit the needs of applications that would demand alternative scheduling and synchronization paradigms, and handling quality of service requirements.
• Its execution time is between 5ms and 6ms.
• Section 3 explains the scheduler architecture and execution semantics, while section 4 describes their methodology for synthesizing an application-dependent scheduler.

2 Model Generation

• The authors consider real-time Java applications made up of a fixed number of threads that synchronize and communicate through a fixed set of global shared objects.
• Large blocks of source code or to specific statements, such as:lock (corresponding to the Java-bytecodemonitorEnter ), unlock (monitorExit ), wait, waitTimed (the Javawait method with a timeout parameter), andwaitForPeriod (the method of the classPeriodicThread in the Expresso profile, which blocks a thread until its next period).
• This is done to keep the synchronization context consistent during the model extraction process.
• The fact that the threadTh holds the lock ofO is recorded by adding{O} to theΣ of thesynchronized statement.
• These graph-rewrite rules allow us to obtain an extended automaton at the desired level of abstraction for each application thread.

3.1 Architecture

• The architecture of the schedulers the authors synthesize consists of two three-layered stacks [7], as shown in Fig.
• The left stack selects a thread for execution.
• The reason for this is that the threads which will be notified (if any) cannot ever be selected for execution.
• The middle layerSafe-Notif, calculates the subsetSnotif of Rnotif consisting of those threads which, if notified, will not cause the system to enter into a deadlock state or to miss a deadline.
• In choosing a QoS policy (or policies, since these are composable) the designer can balance between the execution time and extra memory space needed by the policy and the gains to the overall system quality the particular policy can offer.

3.2 Semantics

• The model of the system the authors construct is the parallel composition of:(i) an automaton which is responsible for advancing time and firing timeouts,(ii) one automaton for each of the application threads, and(iii) two more automata, for theQoS-Execand theQoSNotif scheduler layers respectively.
• The application automata are those obtained from the Java source code, appropriately annotated with the timing constraints modeling the execution times of the code that has been abstracted away.
• The system goes through three different modes of execution, as shown in Fig. 5(c).
• In the “Time Only” mode (whereExecSchedEnabled = Notif SchedEnabled = true) the automaton responsible for advancing time and firing timeouts (shown in Fig. 5(a)) is the sole automaton enabled in the system and it can fire one or more timeouts, if any is enabled, corresponding to the expiration of awaitTimed orwaitForPeriod.
• If a timeout is fired then the execution mode changes to “Schedulers Only” (where ExecSchedEnabled= ¬Notif SchedEnabled), so that their scheduler can handle it.

4 Scheduler Synthesis

• In order to synthesize theSafe-ExecandSafe-Notifscheduler layers, the authors first construct the set of reachable states and, thus, identify the deadlocks.
• These are the states where the application threads are deadlocked, or the states where some thread has missed its deadline or period (since in that case the authors block the system explicitly).
• The existence of these states indicates that the predicate the authors are currently using to describe the setSexec (resp.Snotif ) needs to be constrained even further.
• Having obtained the deadlocked states, the authors do a backwards traversal of the whole state space starting from the deadlocked states, until they reach a state which corresponds to a choice of one of the scheduler automata.
• There, the authors identify the choiceTExec = ti which allowed the path leading to a deadlock state(s) and create a new constraint for the layerSafe-Exec(resp. Safe-Notif).

4.1 State-Space Reduction and Application Analysis

• Even though the basic idea of synthesizing theSafe-ExecandSafe-Notifscheduler layers is simple, it is evident that in practice it suffers from the state explosion problem.
• The authors then apply the synthesis algorithm again on the parallel composition of the already constrained models.
• The authors examine theuntimed model (U) of the system and search for constraints which can guarantee theabsence of deadlocks.
• Once the authors can indeed safely schedule the system under the hypothesis that threads are never preempted, then they can use the constraints obtained during this step toreduce even furtherthe state space that they have to construct and analyze when they do allow threads to be preempted.
• Therefore, if the authors wish their scheduler to always make a decision which issafe, then theSexec set of thisequivalence classof states should be theintersectionof theSexec sets of the states which belong to the same equivalence class.

5 Scheduler Implementation

• Once the scheduler has been synthesized using the model, it has to be implemented and integrated with the code generated by the TurboJ compiler.
• The application-level scheduler is implemented on top of an accompanying runtime library, which offers an implementation in native code of the aforementioned statements and methods.
• Finally, the authors use three different priority levels, namely,BLOCKED , EXEC & SUPER (from lowest to highest) and theSCHED_FIFOPOSIX scheduling policy (i.e., priority based, FIFO, non-preemptive execution of tasks having the same priority).
• J_Scheduler calls the function Synthesized_Predicates (generated by the synthesis tool) passing it the current labels of all the application threads.
• This final action releasessched mx just before blocking, thus allowing the notified threadtn to resume execution.

6 Conclusions

• The authors have presented a complete application-driven scheduler synthesis chain that allows to automatically generate native code for embedded real-time systems based on Java.
• In addition, it allows one to substitute RMA/EDF & PCP with a scheduler which is still safe but not as pessimistic and which can be easily extended with QoS scheduling policies.
• The authors are not aware of any other similar chain.
• The full integration of the model- generation and scheduler-synthesis tools with the compiler is under test as it requires a close collaboration with the TurboJ development team.

Figures

Fig. 4.Scheduler architecture

Fig. 2.Robotic arm system architecture

Fig. 5.Time & Scheduler automata and system execution modes

Fig. 6.System decomposition

Fig. 3.Graph rewrite rules for the generation of models

Table 2.Synthesis steps

Fig. 1.Code analysis & generation chain

Table 1.Model abstractions and optimizations

Table 3.Pseudo-code of the application scheduler

Full text

City, University of London Institutional Repository
Citation: Kloukinas, C., Nakhli, C. and Yovine, S. (2003). A Methodology and Tool Support
for Generating Scheduled Native Code for Real-Time Java Applications. Lecture Notes in
Computer Science: Embedded Software, 2855, pp. 274-289. doi: 10.1007/978-3-540-45212-
6_18
This is the unspecified version of the paper.
This version of the publication may differ from the final published
version.
Permanent repository link: https://openaccess.city.ac.uk/id/eprint/2896/
Link to published version: http://dx.doi.org/10.1007/978-3-540-45212-6_18
Copyright: City Research Online aims to make research outputs of City,
University of London available to a wider audience. Copyright and Moral
Rights remain with the author(s) and/or copyright holders. URLs from
City Research Online may be freely distributed and linked to.
Reuse: Copies of full items can be used for personal research or study,
educational, or not-for-profit purposes without prior permission or
charge. Provided that the authors, title and full bibliographic details are
credited, a hyperlink and/or URL is given for the original metadata page
and the content is not changed in any way.
City Research Online

City Research Online: http://openaccess.city.ac.uk/ publications@city.ac.uk

A methodology and tool support for generating
scheduled native code for real-time Java applications
?
Christos Kloukinas Chaker Nakhli Sergio Yovine
VERIMAG
Centre Equation, 2 Ave. Vignate, 38610 Gi
`
eres, France
{Christos.Kloukinas,Chaker.Nakhli,Sergio.Yovine}@imag.fr
1 Introduction
Current trends in industry are leading towards the use of Java [5] as a programming
language for implementing embedded and real-time applications. From the software
engineering perspective, the Java environment is indeed a very attractive development
framework. Object-oriented programming provides encapsulation of abstractions into
objects that communicate through clearly defined interfaces. Dynamic loading eases
the maintenance and improvement of complex applications with evolving requirements
and functionality. Besides, Java provides built-in support for multi-threading.
However, the semantics of Java do not guarantee a predictable run-time behavior,
which is an essential issue in embedded real-time software. To overcome this problem,
work has been done to extend the language and the platform to accommodate to the
requirements of real-time systems by focusing on current practices. Among such work,
we should mention the Real-Time Specification for Java [11], and the Real-Time Core
Extension for the Java Platform [12], that provide support for real-time programming
(timers, clocks, handlers, priorities, ... ). Still, these extensions leave some important is-
sues unspecified, like the scheduling algorithm to be used, allowing an implementation
to resolve them at will.
In order to obtain more precise semantics, domain-specific profiles have also been
defined, such as the Ravenscar-Java [8] high-integrity profile for safety-critical sys-
tems. This profile settles an execution model based on a two/three-phase program ex-
ecution, comprising an initialization phase and a mission phase (possibly followed by
a termination phase), and multi-threading semantics relying on fixed priority preemp-
tive scheduling and priority ceiling inheritance. Though designed to ease analysis and
programming, this profile still has some drawbacks. For instance, it does not directly
support threads which synchronize and communicate using the wait and notify
methods of Java. Besides, the underlying schedulability analysis is pessimistic by na-
ture and not well adapted for systems with heterogeneous tasks and constraints.
The other important issue is performance. Though there are efforts to produce effi-
cient implementations of Java Virtual Machines (e.g., [1,15]), the slowdown due to the
VM remains an argument against adopting Java for real-time applications. Real-time
systems can afford neither the overhead nor the non-determinism of using a Just-In-
Time (JIT) compiler (e.g., [3,14]). An alternative approach consists in using an Ahead-
?
Partially supported by the RNTL project Expresso (http://www.irisa.fr/rntl-expresso).

of-Time (AOT) compiler (e.g., [10,17]) to generate executable code for a run-time sys-
tem and to provide a native implementation of the real-time primitives. A major advan-
tage of AOT compilation is that it allows performing sophisticated analysis techniques
to produce highly optimized code.
In this paper we present an approach that takes into account the demands of both
precise semantics and performance. Our work is based on the two/three-phase execution
model and API of the Expresso High-Integrity Profile [4], which itself inherits concepts
from the Ravenscar-Java profile and the RTSJ API. However, the semantics proposed by
the profile do not fit the needs of applications that would demand alternative schedul-
ing and synchronization paradigms, and handling quality of service requirements. To
accommodate to such demands, our approach focuses primarily on the application.
Model
Automata
Timed
Scheduler
Synthesis
Table of
Dynamic
Priorities
Program
Java
Information
WCET
Instrumented
Java
Program
Compiler
Java
TurboJ
Executable
Native
Run−Time
RT OS
(POSIX / eCos)
(per state)
Model
Generator
Scheduler
Support Library
Fig.1. Code analysis & generation chain
Following [13], we first extract a formal model of the behavior of the application
program as an extended automaton (see Fig. 1 & section 2). Then, we synthesize an
application-dependent scheduler (see sections 3–4) which is safe (i.e., it is deadlock
free and meets all timing constraints) and QoS extendible (i.e., it can be extended to
handle QoS requirements, such as reducing response jitter, power consumption or con-
text switches). This synthesized scheduler is meant to be used with an appropriate native
run-time support we have developed, which itself uses the underlying R-T OS’s primi-
tives (see section 5). Our scheduler also needs an instrumented version of the original
Java code (also produced by our model extracting tool), so as to be able to follow

the changes of thread states (i.e., the instrumentation implements an abstract program
counter). The test-bed we have developed has been integrated together with the Ex-
presso High-Integrity API and the TurboJ [17] Java-to-native compiler.
This framework provides a complete analysis and compilation chain for embedded
real-time systems based on Java, allowing one to substitute RMA/EDF & PCP with a
scheduler which is still safe but not as pessimistic. In this article, we describe the model
generator, the scheduler architecture and synthesis methodology, and the prototype test-
bed implemented using POSIX [6] primitives.
We will illustrate our approach throughout the paper with a case study inspired
by the robotic arm system described in [9] (see Fig. 2). The arm is programmed to
take objects from a conveyor belt, to store them in a buffer shelf, and to put them
into a basket. The arm is controlled by threads running on a single processor. The
TrajectoryControl thread reads commands from a shared buffer and issues set-
points to the low-level arm controller Controler. If there are no commands to pro-
cess, it holds, otherwise reads sensor values and computes the new set-point. Its ex-
ecution time is between 5ms and 6ms. The Lifter thread is activated periodically
every 40ms. Its role is to command the arm to pick objects from the conveyor belt.
Upon termination, it issues a command to the TrajectoryControl and activates
the Putter. Its execution time is between 4ms to 8ms. The Putter thread sends com-
mands to take the object from the buffer shelf and put it into the basket. Its execution
time is between 4ms to 8ms. The SensorReader thread reads sensors every 24ms. Its
execution time is 1ms. The results of the sensors are used by TrajectoryControl.
Controler is a periodic thread with period 16ms. Notice in Fig. 2 how, according
to the Expresso HIP-API,
waitForPeriod
returns a boolean value which is
false
if the
thread misses its period. In such a case, the application ends the mission phase and
goes into a termination phase which is omitted here. In this paper we only consider the
problem of synthesizing a scheduler for the mission phase.
The paper is organized as follows. Section 2 presents the technique we use to gen-
erate models from Java source code. Section 3 explains the scheduler architecture and
execution semantics, while section 4 describes our methodology for synthesizing an
application-dependent scheduler. Section 5 discusses our test-bed implementation.
2 Model Generation
We consider real-time Java applications made up of a fixed number of threads that
synchronize and communicate through a fixed set of global shared objects. There is a
distinguished thread, namely Main, which is the first thread to wake up at application
startup and the unique entry-point of the application. We assume that Main is pro-
grammed according to the Expresso HIP, that is, all the shared objects and threads are
created during the initialization phase.
The model of a Java program is a transition system which abstracts program actions
and states. Each state in the model is an abstraction of a program state at run-time. Tran-
sitions are associated with source code and capture the change that its execution makes
to the program state. More formally, let Θ = {th
i
} be a finite set of threads, Ω = {O
i
}
be a finite set of shared objects, and A be a set of labels. Labels may correspond to