Restrictions of 1ava for Embedded Real-Time Systems

Martin Schoeberl
Strausseng. 2-10/2/55, A-1050 Vienna,
AUSTRIA
martin@jopdesign.com

Abstract
This working paper presents the status of restricted Java
environments for embedded and real-time svstems. It
helps to position the development of JOP. Some ideas for
missing definitions are included at the end.
1 Introduction
Java`s Iirst use was in an embedded system. In the
early 90s Java, whose original name was Oak, was cre-
ated as programming tool Ior a wireless PDA. The device
(called *7) was a small SPARC based hardware with a
tiny embedded OS. *7 did not become a product and Java
was oIIicial released 1995 as new language Ior the inter-
net (to be integrated in Netscape`s browser). Over the
years, Java technology became a programming tool Ior
desktop applications and web services. With every new
release the library (deIined as part oI the language) grow
bigger and bigger.
Java Ior embedded systems was clearly out oI Iocus
Ior Sun. With the arrival oI mobile phones Sun got inter-
ested in this embedded market again. Sun deIined diIIer-
ent subsets oI Java, which are analyzed in this paper.
As the language got popular, with easier object ori-
ented programming than C and threads deIined as part
oI the language, usage in real-time systems was consid-
ered. Two competing groups started to deIine who to
convert Java Ior these systems.
Nilsen published the Iirst paper on this topic in No-
vember oI 1995 |4| and Iormed the Real-Time Working
Group. The other group, known as Real-Time Expert
Group, around Bollela and Gosling (the original designer
oI Java) published the RTSJ (Real-Time SpeciIication Ior
Java) |9|. RTSJ was the Iirst speciIication request under
Suns Java Community Process and got great attention by
academic and industrial research.
For the use oI Java in embedded real-time systems,
several restrictions have been deIined. These restrictions
can be categorized in two groups:
Embedded: Restrict the JVM and reduce the mandatory
library.
Real-Time: DeIine scheduling semantics oI the JVM
more precise and library extension with real-time
classes.
The Iirst part oI the paper gives an overview oI Java
support Ior embedded systems and the known problems.
The second part describes restrictions Ior embedded sys-
tem Iollowed by an overview oI real-time speciIications
Ior Java. II and how these speciIications are suIIicient Ior
small embedded systems in general and Ior JOP (a Java
Optimized Processor) |11| is analyzed. At the end oI this
paper a speciIication Ior Java on embedded real-time
systems is proposed.
2 1ava Support for Embedded Systems
When not using the cyclic executive approach, pro-
gramming oI embedded (real-time) systems is all about
concurrent programming with time constraints. The basic
Iunctions can be summarized as:
Threads
Communication
Activation
Low level hardware access
2.1 Threads and Communication
Java has a built in model Ior concurrency, the class
Thread. All threads share the same heap resulting in a
shared memory communication model. Mutual exclusion
can be deIined on methods or code blocks with the key-
word synchronized. Synchronized methods acquire the
lock on the object oI the method. For synchronized code
blocks, the object to be locked is explicit stated.
2.2 Activation
Every object inherits the methods wait(), notify() and
notifyAll() Irom Object. These methods in conjunction
with synchronization on the object support activation.
The classes java.util.TimerTask and java.util.Timer
(since JDK 1.3) can be used to schedule tasks Ior Iuture
execution in a background thread.
2.3 Problems
Although Java has language Ieatures that simpliIy
concurrent programming the deIinition oI this Ieatures is
too vague Ior real-time systems.
2.3.1 Threads and Svnchroni:ation
Java, as described in |1|, deIines a very loose behavior
oI threads and scheduling. E.g. the speciIication allows
even low priority threads to preempt high priority
threads. This prevents threads Irom starvation in general
purpose applications, but is not acceptable in real-time
programming. Even an implementation without preemp-
tion is allowed.
Wakeup oI a single thread with notify() is not exactly
deIined: The choice is arbitrarv and occurs at the discre-
tion of the implementation.
It is not mandatory Ior a JVM to deal with the priority
inversion problem.
2.3.2 Garbage Collector
Garbage collection greatly simpliIies programming
and helps to avoid classic programming errors (e.g.
memory leaks), but is not suitable Ior real-time systems
and problematic in embedded systems. A more conserva-
tive approach to memory allocation is necessary.
2.3.3 WCET on Interfaces (OOP)
InterIaces (and method overriding), the key concepts
in Java to support object oriented programming, are prob-
lematic Ior WCET analysis like Iunction pointers in C.
Implementation oI interIace look up usually requires a
search oI the class hierarchy or very large dispatch tables.
2.3.4 Dvnamic Class Loading
Dynamic class loading requires resolution and veriIi-
cation oI classes. A Iunction that is usually too complex
(and too memory consuming) Ior embedded devices. Up-
per bound oI execution time Ior this Iunction is almost
impossible to predict (or too large). This results in com-
plete avoidance oI dynamic class loading in real-time
systems.
2.3.5 Standard Librarv
For a Java conIormant implementation, the Iull library
(JDK) has to be part oI it. The JAR Iiles Ior this library
constitutes about 15 MB (in JDK 1.3, without native li-
braries), Iar to big Ior many embedded systems.
Since Java was designed to be a save language with a
save execution environment no classes are deIined Ior
low-level access oI hardware Ieatures.
The standard library was not deIined and coded with
real-time applications in mind.
2.3.6 Implementation Problems
According to |3| the static initializers oI a class C are
executed immediately beIore one oI the Iollowing occurs:
An instance oI C is created.
A static method oI C is invoked.
A static Iield oI C is used or assigned.

Figure 1 shows an example oI this problem:

pub11c c1ass Pob1em {

p1vafe sfaf1c Abc a
pub11c sfaf1c 1nf cnf // 1mp11z1f sef fo 0

sfaf1c {
// do some c1ass 1n1f1a11za1on
a = neW Abc{} //even fh1s 1s ok.
}

pub11c Pob1em{} {
++cnf
}
}
// anyWhee 1n some ofhe c1ass, W1fhouf any
// 1nsfance of Pob1em fh1s can 1ead fo
// execuf1on of fhe 1n1f1a11ze

1nf nOfPob1ems = Pob1em.cnf
Figure 1: Class initialization
It Iollows, that bytecodes getstatic, putstatic and new
can lead to class initialization and possible high WCET
values. In the implementation oI a JVM, it is necessary to
check on ever execution oI these bytecodes iI the class is
already initialized. This leads to a perIormance loss and is
violated in some existing implementations oI the JVM
(e.g. in CACAO |25| the static initializer is called at
compilation time).
Synchronization is possible with methods and on code
blocks. Each object has a monitor associated with it.
There are two diIIerent ways to gain and release owner-
ship oI this monitor. Bytecodes monitorenter and moni-
torexit explicite handle synchronization. Otherwise, syn-
chronized methods are marked in the class Iile with ac-
cess Ilags to be synchronized. This means that all byte-
codes Ior method invocation and return must check this
access Ilag. This results in an unnecessary overhead on
methods without synchronization. A better way would be
to encapsulate the bytecode oI synchronized methods
with bytecodes monitorenter and monitorexit. This solu-
tion is used in Suns picoJava-II |12|. The code is manipu-
lated in the class loader.
Two diIIerent ways to code synchronization, in the
bytecode stream and as access Ilags, are inconsistent.
3 1ava Micro Edition
The deIinition oI Java also includes the deIinition oI
the class library (JDK). This is a huge library and too
large Ior some systems. To compensate Ior this Sun has
deIined the Java 2 Platform, Micro Edition (J2ME) |17|.
As Sun has changed several times the Iocus oI Java tar-
gets the speciIications reIlect this in a little chaotic man-
ner. J2ME reduces the Iunction oI the JVM (e.g. no Iloat-
ing point support) to ease implementation on smaller
processors and reduces the library (API).
J2ME deIines three layers oI soItware built upon the
host operating system oI the device:
1ava Virtual Machine: This layer is just the JVM as in
every Java implementation. It is assumed by Sun
that the JVM is implemented on top oI a host operat-
ing system. There are no additional deIinitions Ior
the J2ME in this layer.
Configuration: The conIiguration deIines the minimum
set oI JVM Ieatures and Java class libraries available
on a particular category oI devices. In a way, a con-
Iiguration deIines the lowest common denominator
oI the Java platIorm Ieatures and libraries that the
developers can assume to be available on all de-
vices.
Profile: The proIile deIines the minimum set oI Applica-
tion Programming InterIaces (APIs) available on a
particular Iamily oI devices. ProIiles are imple-
mented upon a particular conIiguration. Applica-
tions are written Ior a particular proIile and are thus
portable to any device that supports that proIile. A
device can support multiple proIiles.
There is an overlap oI the layers configuration and
profile: Both deIine/restrict Java class libraries.
Sun states: A profile is an additional wav of specifv-
ing the subset of Java APIs, class libraries, and virtual
machine features that targets a specific familv of de-
vices. However, in the current available deIinitions JVM
Ieatures are only speciIied in configurations.
3.1 Connected Limited Device Configuration
(CLDC)
CLDC is a conIiguration Ior connected devices with at
least 192 kB oI total memory and a 16-bit or 32-bit proc-
essor. This conIiguration got very popular since the main
target devices are cellular phones (Sun: CLDC was de-
signed to meet the rigorous memorv footprint require-
ments of cellular phones.`). The CLDC is composed oI
the K Virtual Machine (KVM) and core class libraries.
Following Ieatures area removed Irom the Java lan-
guage deIinition:
No Iloating point support
No Iinalization

Error handling is changed in the way that the JVM
halts in an implementation-speciIic manner.
Following Ieatures are removed Irom the JVM
Floating point support
Java Native InterIace (JNI)
ReIlection
Finalization
Weak reIerences
User-deIined class loaders
Thread groups and daemon threads
Asynchronous exceptions
Data type long is optional

These restrictions are deIined in the Iinal version 1.0
oI CLDC. A newer version (1.1) adds Iloating-point sup-
port again. All currently available devices (as listed by
Sun) support version 1.0.
The CLDC deIines a subset oI Iollowing Java class li-
braries: java.io, java.lang, java.lang.ref and java.util.
An additional library (javax.microedition.io) deIines a
simpler interIace Ior communication than java.io and
java.net. Examples oI connections are: HTTP, datagrams,
sockets and communication ports.
A small-Iootprint JVM called K Virtual Machine
(KVM) is part oI the CLDC distribution. KVM is suitable
Ior 16/32-bit microprocessors with a total memory budget
oI about 128 kB.
An implementation oI CLDC may choose to pre-
load/prelink some classes. A utility (JavaCodeCompact)
combines one or more Java class Iiles and produces a C
Iiles that can be compiled and linked directly with the
KVM.
There is only one proIile deIined under CLDC: The
Mobile InIormation Device ProIile (MIDP) deIines a user
interIace Ior LC displays, a media player and a game
API.
3.2 Connected Device Configuration (CDC)
The CDC deIines a conIiguration Ior devices with
network connection and assumes at minimum a 32-bit
processor and 2 MB memory. CDC deIines no restric-
tions Ior the JVM. A virtual machine, the CVM, is part oI
the distribution. The CVM expects Iollowing Iunctional-
ity Irom the underlying OS:
Threads
Synchronization (mutexes and condition variables)
Dynamic linking
malloc (POSIX memory allocation utility) or
equivalent
Input/output (I/O) Iunctions
Berkeley Standard Distribution (BSD) sockets
File system support
Function libraries must be thread-saIe. A thread
blocking in a library should not block any other VM
threads.

The tools JavaCodeCompact and JavaMemberDepend
are part oI the distribution. JavaMemberDepend gener-
ates lists oI dependencies at the class member level. The
existence oI JavaCodeCompact implies that preloading
oI classes is allowed in CDC.
Three proIiles are deIined Ior CDC:
Foundation Profile is a set oI Java APIs that support
resource-constrained devices without a standards-
based GUI system. The basic class libraries Irom the
Java standard edition (like java.io, java.lang and
java.net) are supported and a connection Iramework
(javax.microedition.io) is added.
Personal Basis Profile is a set oI Java APIs that support
resource-constrained devices with a standards-based
GUI Iramework based on lightweight components. It
adds some parts oI the Abstract Window Toolkit
(AWT) support (relative to JDK 1.1 AWT).
Personal Profile completes the AWT libraries and in-
cludes support Ior the applet interIace.
Although a device can support multiple proIiles addi-
tional libraries Ior RMI and ODBC are called optional
packages.
3.3 Additional Specifications
The Iollowing speciIications don`t Iit in the layer
scheme oI J2ME. However, they deIine like the above
subsets oI the JVM and subsets/extensions oI Java classes
(API):
1ava Card is a deIinition Ior the resource-constraint
world oI smart cards. The execution liIetime oI the
JVM is the liIetime oI the card. The JVM is very re-
stricted (e.g. no threads, data type int is optional) and
deIines a diIIerent instructions set (i.e. new byte-
codes to support smaller integer types).
1ava Embedded Server is an API deIinition Ior services
like HTTP.
Personal 1ava was intended as a Java platIorm on Win-
dows CE and is now marked as end oI liIe.
1ava TV is an extension to produce interactive television
content and manage digital media. It is described
that the JVM runs on top oI a RTOS, but no real-
time speciIic extensions are deIined.

Only view speciIications Ior embedded Java exist
other than Sun`s:
le1OS |18| is a JVM Ior Lego Mindstorm with stronger
restrictions on the core classes than the CLDC.
RTDA |23| although named Real-Time Data Access`
the deIinition consists oI two parts:
An I/O data access API speciIication applicable Ior
real-time and non real-time applications.
A minimal set oI real-time extensions to enable the
I/O data access to also cover hard real-time capable
response handling.
3.4 Discussion
Many oI the speciIication (i.e. configurations and pro-
files) are developed using the Java Community Process
(JCP). JCP is not an open standard nor does it Iit to the
idea oI open source. Although the acronym J2ME implies
Java version 2 (i.e. JDK 1.2 and later) almost all tech-
nologies under J2ME are still based on JDK 1.1.
CLDC is (besides Java Card) the smallest` deIinition
Irom Sun. It assumes an operating system and is quite
large (the JAR Iile Ior the classes is about 450 kB). There
are no API deIinitions Ior low-level hardware access.
CLDC is not suitable Ior small embedded devices. Java
Card deIines a diIIerent JVM instruction set and thus
compromises basic ideas oI Java.
A more restricted deIinition with Iollowing Ieatures is
needed:
JVM restrictions like in CLDC 1.0
A package Ior low-level hardware access
Minimum subset oI core libraries
Additional proIiles Ior application domains
4 Real-Time Extensions
In 1999, a document deIining the requirements Ior
real-time Java was published by NIST |21|. Based on this
requirements two groups deIined speciIications Ior real-
time Java. A comparison oI these two speciIications and
to Ada 95`s Real-Time Annex can be Iound in |10|. The
Iollowing section gives and overview oI these speciIica-
tions and additional deIined restrictions oI RTSJ.
4.1 Real-Time Core Extension
The Real-Time Core Extension |20| is a speciIication
published under the J Consortium. It is still a draIt ver-
sion.
Two execution environments are deIined: The Core
environment is the special real-time component. It can be
combined with a traditional JVM, the Baseline. For com-
munication between these two domains, every Core
object has two APIs, one Ior the Core domain and one Ior
the Baseline domain. Baseline components can synchro-
nize with Core components via semaphores.
Two Iorms oI source code are supported to annotate
attributes: stvli:ed code with calls oI static methods oI
special classes and svntactic code with new keywords.
Syntactic code has to be processed by a special compiler
or preprocessor.
4.1.1 Memorv
A new object hierarchy with CoreObject as root is in-
troduced. To override Iinal methods Irom Object the se-
mantics oI the class loader is changed. It replaces these
methods with special named methods Irom CoreObject. A
Core task is only allowed to allocate instances oI
CoreObject and its subclasses. These objects are allocated
in a special allocation context or on the stack. The objects
are not garbage collected. However, an allocation context
can be explicit Ireed by the application.
4.1.2 Tasks and Asvnchronv
Core tasks represent the analog oI java.lang.Threads.
All real-time tasks must extend CoreTask or one oI its
subclasses. No interIace like java.lang.Runnable is de-
Iined. Tasks are scheduled preemptive priority-based
(128 levels) with FIFO within priorities. Time slicing can
be supported, but is not required.
Although stop() is depreciated in Java 2 it is allowed
in the CoreTask Ior asynchronous transIer oI control (be-
sides a class ATCEvent). To prevent the problem oI in-
consistent objects aIter stopping a task an atomic syn-
chronized` region deIers abortion.
A special task class is deIined to implement interrupt
service routines. The code Ior this handler is executed
atomic and must be WCET analyzable. SporadicTask is
used to implement responses to sporadic events, triggered
by invoking the trigger() method oI the task. No enIorce-
ment oI minimum time between arrivals oI events is
available.
No special events or task types are deIined Ior peri-
odic work. The methods sleep() and sleepUntil() oI Core-
Task can be used to program periodic activity.
4.1.3 Exceptions
ReIerences Irom the java.lang.Throwable class hierar-
chy are silently replaced by the class loader with reIer-
ences to Core classes. A new scoped exception, which
needs special support Irom the JVM, is deIined.
4.1.4 Svnchroni:ation
snychronized is only allowed on this. To compensate
Ior this restriction additional synchronization objects like
semaphores and mutexes are deIined. Queues on moni-
tors, locks and semaphores are priority and FIFO ordered.
Priority inversion is avoided by using the priority ceiling
protocol. To allow an implementation oI locks without
waiting queues a Core task is not allowed to execute a
blocking operation while it holds a lock.
4.1.5 Helper Classes
The standard representation oI time is a long (64-bit)
integer with nanosecond resolution. A Time class with
only static methods is provided Ior conversions. A helper
class supports treating signed integers as unsigned values.
Low-level hardware ports can be accessed via OPort.
4.1.6 Discussion
A new introduced object hierarchy and new language
keywords lead to changes in the class veriIier and loader
semantics. The behavior oI the JVM is changed anyway,
so it would make sense to change the methods oI Object
in a way to Iit to the Core deIinition. This would result in
a single object hierarchy. The restriction on synchronized
disables the elegant style oI expressing general synchro-
nization problems in Java.
Although Nilsen lead the group NewMonics PERC
systems |22| supports a diIIerent API.
4.2 RTS1
The Real-Time SpeciIication Ior Java (RTSJ) deIines a
new API with support Irom the JVM |9|. Following guid-
ing principles led to the deIinition:
No restriction oI the Java runtime environment
Backward compatibility Ior non-real-time Java pro-
grams
No syntactic extension to the Java language or new
keywords
Predictable execution
Current practice and allow Iuture implementations to
add advanced Ieatures

A ReIerence Implementation (RI) oI RTSJ is part oI
the speciIication. RTSJ shall be backward compatible
with existing non-real-time Java programs, which implies
that RTSJ is intended to run on top oI J2SE (and not on
J2ME). The Iollowing section presents an overview oI
the RTSJ.
4.2.1 Threads and Scheduling
A priority-based, preemptive scheduler with at least 28
real-time priorities is deIined a base scheduler. Addi-
tional levels (ten) Ior the traditional Java threads have to
be available. Threads with the same priority are queued
in FITO order. Additional schedulers (e.g. EDF) can be
dynamic loaded. The class Scheduler and associated
classes provide optional support Ior Ieasibility analysis.
Any instances oI classes that implement the interIace
Schedulable are scheduled. In RTSJ RealtimeThread,
NoHeapRealtimeThread, and AsyncEventHandler are
schedulable obfects. NoHeapRealtimeThread has and
AsyncEventHandler can have a priority higher than the
garbage collector. As the available release-parameters
indicate, threads are ether periodic or asynchronous
events. Threads can be grouped together to bind execu-
tion cost and deadline Ior a period.
4.2.2 Memorv
As garbage collection is problematic in real-time ap-
plication RTSJ deIines new memory areas:
Scoped memory is a memory area with bound liIetime.
When a scope is entered (with a new thread or
through enter()) all new objects are allocated in this
memory area. Scoped memory areas can be nested
and shared among threads. On exit oI the last thread
Irom a scope, all Iinalizers oI the allocated objects
are invoked and the memory area is Ireed.
Physical memory is used to control allocation in memo-
ries with diIIerent access time.
Raw memory allows byte-level access to physical mem-
ory or memory-mapped I/O.
Immortal memory is a memory shared between all
threads without a garbage collector. All objects cre-
ated in this memory area have the same live time as
the application (a new deIinition oI immortal).
Heap memory is the traditional garbage collected mem-
ory.

Maximum memory usage and the maximum allocation
rate per thread can be limited. Strict assignment rules
between the diIIerent memory areas have to be checked
by the implementation.
4.2.3 Svnchroni:ation
The implementation oI synchronized has to include an
algorithm to prevent priority inversion. Priority inheri-
tance protocol is the deIault and priority ceiling can be
used on request. Threads waiting to enter a synchronized
block are priority and FIFO within priority ordered. Wait
Iree queues are provided Ior communication between
instances oI java.lang.Thread and RealtimeThread.
4.2.4 Time and Timers
Classes to represent relative and absolute time with
nanosecond accuracy are deIined. All time parameters are
split to a long Ior milliseconds and an int Ior nanoseconds
within millisecond. Each time object has an associated
Clock object. Multiple clocks can represent diIIerent
sources oI time and resolution. This allows reduction oI
queue management overhead Ior tasks with diIIerent tol-
erance Ior jitter. A new type, rationale time, can be used
to describe periods with a requested resolution over a
larger period (i.e. allowing release jitter between the
points oI the outer period). Timer classes can generate
time-triggered events (one shot and periodic).
4.2.5 Asvnchronv
Program logic representing external world events is
scheduled and dispatched by the scheduler. An
AsyncEvent object represents an external event (like a
POSIX signal or a hardware interrupt) or an internal
event (through call oI fire()). Event handler are associated
to these events and can be bound to a regular real-time
thread or represent itselI something similar to a thread.
The relation ship between events and handlers can be
many-to-many. Release oI handlers can be restricted to a
minimum interarrivel time.
Java`s exception handling is extended to represent
asynchronous transIer oI control (ATC). RealtimeThread
overloads interrupt() to generate an Asynchronousnter-
ruptedException (AIE). The AEI is deIerred until execu-
tion oI a method that is willing to accept ATC. The
method indicates this by including AIE in its throw
clause. Semantics oI catch is changed so, that even when
it catches an AIE, the AIE is still propagated until the
happened method oI the AIE is invoked. Timed, a sub-
class oI AIE, simpliIies programming oI timeouts.
4.2.6 Support for RTSJ
Implementations oI RTSJ are still rare and under de-
velopment:
RI is the Iree available reIerence implementation Ior a
Linux system |19|.
jRate is an open-source implementation based on ahead-
oI-time compilation with GNU compiler Ior Java
|13|.
a1ile supports RTSJ with CLDC 1.0 on top oI the aJ-80
and aJ-100 chips.
4.3 Discussion on the RTS1
RTSJ is a complex speciIication leading to a big mem-
ory Iootprint. Size oI the RI on Linux:
Classes in javax/realtime: 343 kB
All classes in library Ioundation.jar: 2 MB
Timesys JVM executable: 2.6 MB

RI assumes a RTOS, which runs on a heavy weight
RT-Linux system. RTSJ is too complex Ior low-end em-
bedded systems. The complexity also hampers program-
ming oI high-integrity applications.
Runtime memory allocation oI the RTSJ classes is not
documented.
4.3.1 Threads and Scheduling
II a real-time thread is preempted by a higher priority
thread, it is not deIined iI the preempted thread is placed
in Iront or back oI the waiting queue. It is not speciIied iI
the deIault scheduler perIorms, or has to perIorm, time
slicing between threads oI equal priority.
4.3.2 Memorv
It would be ideal Ior real-time systems to allocate all
memory at the initialization phase and Iorbid dynamic
memory in the mission phase. However, this restricts
many library Iunctions oI Java.
The Solution to this problem in RTSJ is ScopedMem-
ory, a memory space with limited liIetime. However, it
can only be used as parameter on thread creation or with
enter(Runnable r). On a system without dynamic thread
creation using scoped memory at creation time oI the
thread behaves like immortal memory. The syntax with
enter() leads to cumbersome programming style: For each
code part where limited liIetime memory is needed a new
class has to be deIined and a single instance oI this object
allocated at initialization time. Trying to solve this prob-
lem elegant with anonymous classes, like in Figure 2
(example Irom |8| p. 623), leads to an error.

1mpof avax.ea1f1me."
pub11c c1ass 1headCode 1mp1emenfs kunnab1e
{
p1vafe vo1d compufaf1on{}
{
f1na1 1nf m1n = 1"1024
f1na1 1nf max = 1"1024
f1na1 L1Memoy myMem = neW
L1Memeoy{m1n, max}
myMem.enfe{neW kunnab1e{}
{
pub11c vo1d un{}
{
// access fo fempoay memoy
{
} }
}

pub11c vo1d un{}
{
...
compufaf1on{}
...
}
}
Figure 2: Example of scoped memory usage
On every call oI computation() an object oI the
anonymous class (and a LTMemory object) is allocated in
immortal memory leading to a memory leak.
A simpler syntax is shown in Figure 3. The main
drawback oI this syntax is that correct usage is in the
responsibility oI the programmer.

L1Memoy myMem

// ceafe memoy once 1n consfucfo
My1head{} {
myMem = neW L1Memeoy{m1n, max}
...
}

pub11c vo1d un{} {

...
myMem.enfe{}
{ // neW code b1ock d1sab1es access
// fo neW obecfs 1n oufe scope.
// access fo fempoay memoy
Abc a = neW Abc{}
...
}
myMem.ex1f{}
...
}
Figure 3: Simpler syntax for scoped memory
New objects and arrays oI objects have to be initial-
ized to their deIault value aIter allocation |3|. This usu-
ally results in zeroing the memory at the JVM level and
leads to variable (but linear) time at the allocation. This is
the reason Ior the type LTMemoryArea in the RTSJ. As in
|13| suggested this initialization could be lumped to-
gether to the creation time and exit time oI the scoped
memory. This results in constant time Ior allocation (and
usually Iaster zeroing oI the memory).
4.3.3 Time and Timers
Why is the Time split to milliseconds and nanosec-
onds? In the RI it is converted to ns Ior add/subtract. AI-
ter all mapping and converting (AbsoluteTime, HighReso-
lutionTime, Clock and RealTimeClock) the time oI Sys-
tem.currentTimeMillis() is used.
Since time triggered release oI tasks can be modeled
with periodic threads, the additional concept oI timers is
superIluous.
4.3.4 Asvnchronv
An unbound AsyncEventHandler is not allowed to en-
ter() a scoped memory. However, it is not clear iI scoped
memory is allowed as parameter on construction oI a
handler. Unbound AsyncEventHandler leads to an im-
plicit start oI threads on an event. This can (and does in
the RI, see |13|) lead to substantial overhead. From the
application view bound and unbound event handler be-
have equal. This is an implementation hint expressed
through diIIerent classes.
The syntax to declare acceptance oI ATC in the throws
clause oI a method is misleading. Exceptions in throws
clauses are usually generated in a method and not ac-
cepted.
4.3.5 Missing Features
There is no concept like start mission. Changing
scheduling parameters during runtime can lead to incon-
sistent scheduling behavior
There is no provision Ior low-level blocking like dis-
abling interrupts. This is a common technique in device
drivers where some hardware operations must be atomic
without aIIecting the priority level oI the requesting
thread (e.g. a low priority thread Ior a Ilash Iile system
shall not get preempted during sector write since the chip
internal write starts aIter a timeout).
4.3.6 On Small Svstems
Many embedded systems are still built with 8 or 16-bit
CPUs. 32-bit processors are seldom used. Java`s deIault
integer type is 32-bit, still large enough Ior almost all
data types needed in embedded systems. Why are (per-
haps expensive) longs (64 bit integer) used in the RTSJ?
4.4 Subsets of RTS1
RTSJ is complex to implement and applications de-
veloped with RTSJ are (due to some sophisticated Iea-
tures oI the RTSJ) diIIicult to analyze. DiIIerent proIiles
Ior high-integrity real-time applications, resulting in re-
strictions oI the RTSJ, have been suggested.
4.4.1 A Profile for High-Integritv Real-Time Java
Programs
In |14| a subset oI the RTSJ Ior high-integrity applica-
tion domain, with hard real-time constraints, is proposed.
It is inspired by the Ravenscar proIile Ior Ada |24| and
the Iocus is on exact temporal predictability.
Application structure: The application is divided in two
diIIerent phases: initiali:ation and mission. All non
time-critical initilization, thread creation and startup,
global object allocations are perIormed in the ini-
tialization phase. All classes have to be loaded and
initialized in this phase. AIter return Irom main(),
which is assumed to execute with maximum priority,
the mission phase starts. The number oI threads is
Iixed and assigned priorities remain unchanged.
Threads: Two types oI tasks are deIined: Periodic time-
triggered activities execute an inIinite loop with at
least one call oI waitForNextPeriod(). Sporadic ac-
tivities are modeled with a new class SporadicEvent.
A SporadicEvent is bound to a thread and an exter-
nal event on creation. Unbound event handler are
not allowed. It is not clear iI programatic trigger oI
the event is allowed (invocation oI fire()). A restric-
tion Ior a minimum interarrivel time oI events is not
deIined. Timers are not supported since time-
triggered activities are well supported by periodic
threads. Asynchronous transIer oI control, overrun
and miss handles and calls to sleep() are not al-
lowed.
Concurrency: Synchronized methods with priority ceil-
ing protocol provide mutual exclusion to shared re-
sources. Threads are dispatched in FIFO order
within each priority level. Sporadic events are used
instead oI wait, notify and notifyAll Ior signaling.
Memory: Since garbage collection is still not time pre-
dictable it is not supported. This implicit converts
the traditional heap to immortal memory. Scoped
memory (LTMemory) is provided Ior object alloca-
tion during mission phase. LTMemory has to be cre-
ated during the initialization phase with initial-size
equal maximum size.
Implementation: For each thread and Ior the operations
oI the JVM WCET must be computable. Code is re-
stricted to bound loops and bound recursions. Anno-
tations Ior WCET analysis are suggested. The JVM
has to check timing oI events and thread execution.
It is not stated how the JVM should react on a tim-
ing error.
4.4.2 Ravenscar-Java
Ravenscar-Java proIile |15| is a restricted subset oI
RTSJ and based on previous mentioned work (4.4.1). As
the name implies it resembles ideas oI Ravenscar Ada
|24| in Java.
To simpliIy the initialization phase RJ deIines nitial-
izer, a class that has to be extended by the application
class which contains main(). Usage oI time scoped mem-
ory is Iurther restricted. LTMemory areas are not allowed
to be nested nor shared between threads. Traditional Java
threads are disallowed by changing the class
java.lang.Thread. The same is true Ior all schedulable
objects Irom the RTSJ. Two new classes are deIined:
PeriodicThread where run() gets called periodically,
removing the loop construct with waitForNextPe-
riod().
SporadicEventHandler binds a single thread with a
single event. The event can be an interrupt or a soIt-
ware event.
Is the binding between an event and the handler 1.1?
4.4.3 Critics on Subsets of the RTSJ
II only a subset oI RTSJ is implemented and allowed
it`s harder Ior programmers to Iind out what is available
and what not. This Iorm oI compatibility` leads to con-
Iusion. Use oI diIIerent classes Ior a diIIerent speciIica-
tion is clearer and less error prone.
Ravenscar-Java as deIined in |14| is a subset oI the
RTSJ. It is claimed to be compatible with RTSJ in the
sense that programs written according to the proIile are
valid RTSJ programs. However, (mandatory) usages oI
new classes like PeriodicThread need an emulation layer
to run on a RTSJ system. In this case, it is better to deIine
complete new classes Ior a subset and provide the map-
ping to RTSJ. This leads to clearer distinction between
the two deIinitions.
Ravenscar-Java is not compatible with RTSJ in two
ways: syntax and semantics.
It is not necessary to distinguish between heap and
immortal memory. Without a garbage collector heap is
implicit immortal memory.
Objects are allocated in the initialization phase in im-
mortal memory. In the mission phase, no objects should
be allocated in immortal memory. Scoped memory can be
entered and subsequent new objects are allocated in the
scoped memory area. Since there is no situation where
allocation on these two memory area are mixed no newn-
stance(..) like in the RTSJ or in Ravenscar-Java are nec-
essary.
4.5 Extensions to RTS1
Distribute RT systems, RMI
5 Proposed Definitions for Small Em-
bedded Systems
Restrictions on Java like the available conIigurations
and proIiles oI J2ME and the RTSJ are still too large and
complex Ior small embedded real-time systems. Simpler
deIinition as are proposed: A configuration restricts the
Iunction oI the JVM and the necessary library. Class
deIinitions Ior low-level I/O are added. On top oI this
conIiguration, a profile Ior high-integrity real-time appli-
cation is deIined.
5.1 Small Embedded Devices Configuration
(SEDC)
SEDC is a conIiguration that Iits in Sun`s J2ME layer
model. It is intended Ior small embedded devices with a
16-bit (or even 8-bit) microprocessor and a low memory
budget (below 128 kB). The JVM restrictions are similar
to CLDC 1.0, the subset oI the Java classes is smaller.
5.1.1 Restrictions of the JJM
Following Ieatures are removed Irom the JVM:
Floating point support
Data type long is optional
Java Native InterIace (JNI)
ReIlection
Weak reIerences
Class loading is optional
Threads ?
Thread groups and daemon threads
Finalization oI class instances
Asynchronous exceptions

To simpliIy the JVM the application is preveriIied and
preloaded (and perhaps linked with the JVM).
Since small embedded devices have no or a very sim-
ple user interIace (like switches and LEDs) usually no
stream input/output Iacilities are necessary. As memory is
very limited, the Java class library is reduced to the abso-
lute minimum. Only Iollowing classes have to be avail-
able:
ava.1ang.Obecf
ava.1ang.5f1ng
ava.1ang.1head ?

Shall threads be part of SEDC? There are no threads
e.g. in Java Card and we define new thread behavior
(with real-time semantics) anvwav in an extra profile.
An additional library is provided Ior low-level I/O-
access (package javax.embsys).
Question: What package name can we choose? javax.*
is in the name space oI Sun.
5.1.2 Class IOPort
Static methods oI this class allow application low-
level access to I/O ports.
p1vafe lOPof lOPof lOPof lOPof{}
No instantiation oI this class is allowed.
pub11c sfaf1c 1nf ead ead ead ead{1nf addess}
Read Irom I/O port.
pub11c sfaf1c vo1d W1fe W1fe W1fe W1fe{1nf va1ue, 1nf addess}
Write to I/O port.
5.1.3 Class Clock
Almost all microcontroller have some kind oI timer or
counter. The class Clock provides a standard way to
query counter values.
pub11c sfaf1c 1nf counf counf counf counf{}
Return the current time in clock ticks. Tick Irequency
is device dependent and can be queried.
pub11c sfaf1c 1nf f1cksPe5econd f1cksPe5econd f1cksPe5econd f1cksPe5econd{}
Returns the resolution oI the clock.
pub11c sfaf1c 1nf f1cksPeMs f1cksPeMs f1cksPeMs f1cksPeMs{}
Returns the resolution oI the clock per millisecond.
This method is necessary iI the clock Irequency leads to
an overIlow oI int i.e. it is higher than 2.15 GHz.
pub11c sfaf1c 1nf eso1uf eso1uf eso1uf eso1uf1onln81fs 1onln81fs 1onln81fs 1onln81fs{}
Returns the length oI the internal clock in bits.
5.1.4 Class Interrupt
Interrupt handler must extend the class nterrupt and
register itselI on an interrupt. For simple blocking, all
interrupts can be disabled.
pub11c sfaf1c vo1d enab1e enab1e enab1e enab1e{}
Is a general enable oI interrupts. Individual masking oI
interrupts is device speciIic and is handled via OPort.
pub11c sfaf1c vo1d d1sab1e d1sab1e d1sab1e d1sab1e{}
Disables all interrupts (like cli on x86).
pub11c sfaf1c lnfeupf eg1sfe eg1sfe eg1sfe eg1sfe{1nf numbe}
An object registers itselI with this method. The inter-
rupt number is device dependent. A previous installed
handler is returned (or null).
pub11c absfacf vo1d hand1e hand1e hand1e hand1e{}
An interrupt causes the object's handle method to be
called.
5.2 A Real-Time Profile for Embedded 1ava
A simple real-time proIile is deIined in the idea oI the
ADA Ravenscar proIile |24|. It resembles the ideas Irom
|14| and |15| but is not compatible with RTSJ. Since the
application domain Ior RTSJ is diIIerent Irom high-
integrity systems, it makes sense to be not compatible
with RTSJ. Restrictions can be enIorced by deIinition oI
new classes (e.g. setting thread priority only in the con-
structor oI a real-time thread, enIorcing minimum interar-
rivel times Ior sporadic events). It is simpler and cleaner
to state what is possible with a particular proIile instead
oI taking a large deIinition and deIine what is not avail-
able.
This proIile addresses the same devices as SEDC (oI
course it is not restricted to small devices). With an emu-
lation layer, it should be possible to run programs written
Ior this speciIication on top oI RTSJ.
The guidelines:
High-integrity proIile.
Easy syntax, simplicity.
Easy to implement.
Low runtime overhead.
No syntactic extension oI Java.
Minimum change oI Java semantics.
Support Ior time measurement iI WCET analysis
tools are not available.
Known overhead (Documentation oI runtime behav-
ior and memory requirement oI every JVM opera-
tion and all provided methods).
Implementation possible on top oI SEDC.

Real-time Java programs on a standard JVM (can) re-
sult in soIt real-time systems Ior low cost devices (e.g.
control loops can accept deadline misses |x|). Emulation
Ior a standard JVM will be provided.
5.2.1 Application Structure
Following restrictions apply to the application:
Initialization and mission phase.
Fixed number oI threads.
Threads are created at initialization phase.
All shared objects are allocated at initialization.
5.2.2 Threads
Three schedulable objects are deIined:
RtThread represents a periodic task. As usual task work is
coded in run() which gets called on missionStart(). A
scoped memory object can be attached to a RtThread
at creation.
HwEvent represents an interrupt with a minimum interar-
rivel time. II the hardware generates more interrupts,
they get lost (or delayed?).
SwEvent represents a soItware-generated event. It is trig-
gered with fire() and has to override handle().

Figure 4 shows the deIinition oI the basic classes.

pub11c absfacf c1ass kf1ask kf1ask kf1ask kf1ask {
pub11c vo1d enfeMemoy enfeMemoy enfeMemoy enfeMemoy{}
pub11c vo1d ex1fMemoy ex1fMemoy ex1fMemoy ex1fMemoy{}
}

pub11c c1ass ke1af1ve11me ke1af1ve11me ke1af1ve11me ke1af1ve11me {

p1vafe ke1af1ve11me ke1af1ve11me ke1af1ve11me ke1af1ve11me{}
pub11c ke1af1ve11me ke1af1ve11me ke1af1ve11me ke1af1ve11me{1nf m1111s}
pub11c ke1af1ve11me ke1af1ve11me ke1af1ve11me ke1af1ve11me{1nf m1111s, 1nf m1co}
}

pub11c c1ass kf1head kf1head kf1head kf1head exfends kf1ask {

p1vafe kf1head kf1head kf1head kf1head{}
pub11c kf1head kf1head kf1head kf1head{1nf p1o1fy,
ke1af1ve11me pe1od}
pub11c kf1head kf1head kf1head kf1head{1nf p1o1fy,
ke1af1ve11me pe1od,
Memoy mem}
pub11c vo1d un un un un{}
pub11c boo1ean Wa1fIoNexfPe Wa1fIoNexfPe Wa1fIoNexfPe Wa1fIoNexfPe1od 1od 1od 1od{}
}

pub11c c1ass hWLvenf hWLvenf hWLvenf hWLvenf exfends kf1ask {

p1vafe hWLvenf hWLvenf hWLvenf hWLvenf{}
pub11c hWLvenf hWLvenf hWLvenf hWLvenf{1nf p1o1fy,
ke1af1ve11me m1n11me,
1nf numbe}
pub11c vo1d hand1e hand1e hand1e hand1e{}
}

pub11c c1ass 5WLvenf 5WLvenf 5WLvenf 5WLvenf exfends kf1ask {

p1vafe 5 55 5WLvenf WLvenf WLvenf WLvenf{}
pub11c 5WLvenf 5WLvenf 5WLvenf 5WLvenf{1nf p1o1fy,
ke1af1ve11me m1n11me}
pub11c f1na1 vo1d f1e f1e f1e f1e{}
pub11c vo1d hand1e hand1e hand1e hand1e{}
}
Figure 4: Schedulable objects
5.2.3 Scheduling
The class Scheduler (see Figure 5) deIines a Iixed pri-
ority scheduler (with FIFO within priorities). Priorities
are divided in three ranges:
Thread: Usual range (1-10) Ior standard Java threads.
SoftRtThread: A range above the Iormer Ior soIt real-time
tasks.
RtThread: This is the range Ior the main hard real-time
application.
Synchronized blocks are executed with priority ceiling
protocol. These blocks are not allowed to be shared be-
tween the three thread classes (How can this be enforced
?).
The scheduler does not dispatch any RtThread or
SoftRtThread until startMission() is called. Standard Java
threads are scheduled during initialization phase, how-
ever usage is discouraged. Scheduling in the mission
phase can be preemptive or non preemptive.
The non-preemptive mode is allowed to eliminate the
cyclic executive coding style without the overhead oI a
Iull preemptive real-time system. The deIinition oI Java
does not regulate preemption and scheduling oI threads.
Even a non-preemptive dispatching model accords with
the speciIication. In |8| it is shown that cooperative
scheduling has a number oI advantages and the schedule
is still analyzable.
A non-preemptive task system is simpler to use since
synchronization on global data between threads is simple
enIorced by not calling yield(). However, it is less reac-
tive than a preemptive system. It deIines Iollowing se-
mantics on thread scheduling:
Threads are never preempted.
Threads are scheduled according their priority.
Threads are scheduled only in these methods:
Thread.yield()
Thread.sleep()
SoftRtThread.sleep()
RtThread.waitForNextnterval()

For non-preemptive mode, these methods are not al-
lowed in synchronized blocks (making synchronized
blocks in this context redundant). The programmer is
responsible to call yield() at proper places.

pub11c f1na1 c1ass 5chedu1e 5chedu1e 5chedu1e 5chedu1e {

p1vafe 5chedu1e 5chedu1e 5chedu1e 5chedu1e{}
pub11c sfaf1c vo1d enab1e enab1e enab1e enab1e{}
pub11c sfaf1c vo1d d1sab1e d1sab1e d1sab1e d1sab1e{}
pub11c sfaf1c vo1d sfafM1ss1on sfafM1ss1on sfafM1ss1on sfafM1ss1on{
boo1ean peempf}
pub11c sfaf1c vo1d sef sef sef sefCe111ngP1o1fy Ce111ngP1o1fy Ce111ngP1o1fy Ce111ngP1o1fy{
Obecf o,
1nf p1o1fy}

}

pub11c c1ass 5offkf1head 5offkf1head 5offkf1head 5offkf1head exfends kf1head {

pub11c 5offkf1head 5offkf1head 5offkf1head 5offkf1head{1nf p1o1fy}
pub11c 5offkf1head 5offkf1head 5offkf1head 5offkf1head{1nf p1o1fy,
Memoy mem}

pub11c vo1d s1eep s1eep s1eep s1eep{ke1af1ve11me f1me}
}
Figure 5: Scheduler
To implement non real-time (or soIt real-time) tasks a
Thread or SoftRtThread is allowed to use combinations oI
sleep() and yield(). The scheduler assigns priorities ac-
cording to the thread type.
disable() stops scheduling (i.e. disables interrupts) and
can be used Ior top priority blocking. This method is pro-
vided Ior device drivers and should be used with care and
only where absolute necessary.
The scheduler will be extended with methods Ior
worst-case time measurement Ior the periodic work and
the longest block between yields. These measured execu-
tion times can be used during development when no
WCET analysis tool is available.
5.2.4 Memorv
The proIile does not support a garbage collector. All
memory allocation should be done at initialization phase.
For new objects during mission phase a scoped memory
is provided. Every scoped memory area can be assigned
to one RtThread or SoftRtThread. It is not allowed to
share a scoped memory between threads. No reIerences
Irom the heap to scoped memory are allowed. Scoped
memory is explicit entered and leIt with calls Irom the
application logic. Memory areas are cleared on creation
and when leaving the scope (call oI exitMemory()) leading
to a memory area with constant allocation time.

pub11c c1ass Memoy Memoy Memoy Memoy {

p1vafe Memoy Memoy Memoy Memoy{}
pub11c Memoy Memoy Memoy Memoy{1nf s1ze}
pub11c Memoy Memoy Memoy Memoy{1nf s1ze,
1nf physAddess}
}
Figure 6: Class Memory
5.2.5 Restriction of Java
A list oI some language Ieatures that should (or must)
be avoided Ior WCET analyzable real-time threads and
bound memory usage:
WCET: Only analyzable language constructs are al-
lowed.
Static class initialization: Move this code to a static
method (e.g. init()) and call it in the initialization
phase.
Inheritance: Reduce usage oI interIaces and overridden
methods.
String concatenation: In immortal memory scope only
String concatenation with string literals is allowed.

A program analysis tool can greatly help to enIorce
these restrictions.
5.2.6 An Example
Figure 7 shows the principle coding oI a worker
thread. An Example Ior creation oI two real-time threads
and an event handler can be seen in Figure 8.

pub11c c1ass Woke exfends kf1head {

p1vafe 5WLvenf evenf

pub11c Woke{1nf p, ke1af1ve11me f,
5WLvenf ev} {

supe{p, f,
// ceafe a scoped memoy aea
neW Memoy{10000}
}
evenf = ev
1n1f{}
}

p1vafe vo1d 1n1f{} {
// a11 1n1f1a1zaf1on sfuff
// has fo be p1aced hee
}

pub11c vo1d un{} {

fo {} {
Wok{} // do some Wok
evenf.f1e{} // and f1e an evenf

// some Wok 1n scoped memoy
enfeMemoy{}
WokW1fhMem{}
ex1fMemoy{}

// Wa1f fo nexf pe1od
1f {!Wa1fIoNexfPe1od{}} {
m1ssedDead11ne{}
}
}
// shou1d neve each fh1s po1nf
}
}
Figure 7: A periodic real-time thread
// ceafe an Lvenf
hand1e h = neW hand1e{
kf1head.MAXPklOkl1Y,
neW ke1af1ve11me{1, 0}
}

// ceafe fWo Woke fheads W1fh
// p1o1f1es accod1ng fo fhe1 pe1ods
IasfWoke fW = neW IasfWoke{
kf1head.MAXPklOkl1Y-1,
neW ke1af1ve11me{2, 0}
}
Woke W = neW Woke{
kf1head.MAXPklOkl1Y-2,
neW ke1af1ve11me{10, 0}, h
}

// change fo m1ss1on phase fo a11
// pe1od1c fheads and evenf hand1e
5chedu1e.sfafM1ss1on{fue}

// do some non ea1-f1me Wok
// and ca11 s1eep{} o y1e1d{}
fo {} {
Wafchdog811nk{}
1head.s1eep{500}
}
Figure 8: Start of the application
5.2.7 Open issues (questions)
Can we allow non/soIt real-time threads and still
meet all requirements Ior a high-integrity system?
Shall threads with equal priority get time sliced?
Without time slicing priority ceiling protocol is sim-
pler to implement.
What happens iI an object is used as monitor Ior
which no ceiling priority is set?
II queuing oI wait() is WCET analyzable (maximum
number oI threads is bound) and the semantics oI
notiIy changed to wake up the thread with the high-
est priority, can we allow wait/notiIy and don`t need
the additional class SwEvent?
How are timeouts programmed in such a high-
integrity proIile?
Can TTA be mapped to this speciIication or RTSJ?
How about a deIinition oI TTA Ior Java?

Basic real-time tasks:
Cyclic
Sporadic
Spontaneous
Ongoing
Spontaneous tasks have to be avoided. Is this also true
Ior ongoing tasks?
6 Conclusion
There exist some deIinition Ior embedded and Ior real-
time systems. CLDC, as restriction Ior embedded sys-
tems, Iits best Ior small systems, but is still large. The
most prominent speciIication Ior real-time Java is RTSJ.
However, this speciIication is complex and large, making
it not the primary choice Ior small embedded systems or
high-integrity systems. Restrictions on the RTSJ can
transIorm the deIinition to a high-integrity proIile, but
inherit the complex API. A very small configuration Ior
embedded systems and a high-integrity real-time profile
that Iits to this conIiguration are presented. The conIigu-
ration and part oI the proIile (the non preemptive sched-
uler) are already implemented on top oI JOP and used in
some applications. Future work will extend it to a pre-
emptive scheduler and an emulation layer on top oI RTSJ
will be provided.
References
|1| K. Arnold and J. Gosling. The Java Programming Lan-
guage. Addison Wesley, 2nd edition, 1997.
|2| J. Gosling, B.Joy, G. Steele and G.Bracha. The Java Lan-
guage Specification. Addison Wesley, 2nd edition, 1997.
|3| T. Lindholm and F. Yellin. The Java Jirtual Machine
Specification. Addison Wesley, 2nd edition, 2000.
|4| K. Nilsen. Issues in the Design and Implementation oI
Real-Time Java, July 1996. Published June 1996 in
Java Developers Journal, republished in Q1 1998 Real-
Time Maga:ine
|5| G. Bernat, A. Burns and A. Wellings. Portable Worst-Case
Execution Time Analysis Using Java Byte Code. In Proc.
6th Euromicro Conference on Real-Time Svstems, pp.81-
88, June 2000
|6| E. Yu-Shing Hu, G. Bernat and A. Wellings. A Static Tim-
ing Analysis Environment Using Java Architecture Ior
SaIety Critical Real-Time Systems. In Proc. 7th IEEE In-
ternational Workshop on Obfect-Oriented Real-Time De-
pendable Svstems, pp 64-71, January 2002
|7| I. Bate, G. Bernat, G. Murphy and P. Puschner. Low-Level
Analysis oI a Portable Java Byte Code WCET Analysis
Framework. In 6th IEEE Real-Time Computing Svstems
and Applications (RTCSA2000), pp.39-48, South Korea,
December 2000
|8| A. Burns and A. Wellings. Real-Time Svstems and Pro-
gramming Languages, Addison Wesley, 3rd edition, 2001.
|9| Bollela, Gosling, Brosgol, Dibble, Furr, Hardin and Trun-
bull. The Real-Time Specification for Java, Addison
Wesley, 1st edition, 2000.
|10| B. Brosgol and B. Dobbing. Real-time convergence oI
Ada and Java. In Proc. of the 2001 annual ACM SIGAda
international conference on Ada, pp.11-26, Bloomington,
MN, 2001
|11| Martin Schoeberl. JOP - a Java Optimized Processor,
available at: http://www.jopdesign.com/
|12| Sun Microsystems. picoJava-II Programmers Reference
Manual. Sun Microsystems, March 1999.
|13| A. Corsaro, D. Schmidt. The Design and PerIormance oI
the jRate Real-Time Java Implementation. Appeared at
the 4th International Svmposium on Distributed Obfects
and Applications, 2002
|14| P. Puschner and A. J. Wellings. A ProIile Ior High Integ-
rity Real-Time Java Programs. In Proceedings of the 4th
IEEE International Svmposium on Obfect-oriented Real-
time distributed Computing (ISORC), 2001
|15| J. Kwon, A. Wellings and S. King. Ravenscar-Java: a high
integrity proIile Ior real-time Java, In Proc. of the 2002
foint ACM-ISCOPE conference on Java Grande, pp. 131-
140, Seattle, Washington, USA, 2002
|16| J. Kwon, A. Wellings, S. King. Predictable memory utili-
zation in the Ravenscar-Java proIile. In Obfect-Oriented
Real-Time Distributed Computing, 2003. Sixth IEEE Inter-
national Svmposium on, pp.267-274, May 2003
|17| Sun Microsystems. Java 2 Platform, Micro Edition
(J2ME), available at: http://java.sun.com/j2me/docs/
|18| leJOS, Java Ior the RCX, available at:
http://lejos.sourceIorge.net/
|19| TimeSys. Real-Time SpeciIication Ior Java ReIerence
Implementation. http://www.timesys.com/
|20| International J Consortium SpeciIication. Real-Time Core
Extensions, DraIt 1.0.14, September 2nd 2000. Available
at http://www.j-consortium.org/
|21| K. Nilsen, L. Carnahan and M. Ruark , editors. Require-
ments Ior Real-Time Extensions Ior the Java PlatIorm.
Published by National Institute of Standards and Technol-
ogv. September 1999. Available at http://www.nist.gov/rt-
java.
|22| K. Nilsen and S. Lee. PERC Real-Time API (Draft 1.3).
NewMonics, July 1998
|23| International J Consortium SpeciIication. Real-Time Data
Access, Release 1.0, November 2001. Available at
http://www.j-consortium.org/
|24| A. Burns and B. Dobbing. The Ravenscar Tasking ProIile
Ior High Integrity Real-Time Programs. In Proc. of the
1998 annual ACM SIGAda international conference on
Ada, pp. 1-6, Washington, D.C., United States, 1998
|25| A. Krall and R. GraIt. CACAO - A 64 bit JavaVM just-in-
time compiler. In G. C. Fox and W. Li, editors, PPoPP97
Workshop on Java for Science and Engineering Computa-
tion, Las Vegas, June 1997.