Roadmap

 Introduction  Scheduling and Schedulable

 Concurrent Programming Objects
 Communication and  Asynchronous Events and
Synchronization Handlers
 Completing the Java Model  Real-Time Threads
 Overview of the RTSJ  Asynchronous Transfer of
 Memory Management Control

 Clocks and Time  Resource Control

 Schedulability Analysis
 Conclusions

© Andy Wellings, 2004

 Memory Management
Lecture aims
 To provide an introduction to memory management
in the RTSJ
 To give an overview of MemoryAreas
 To show an example of Scoped Memory Usage
 To consider how to estimating the size of objects

© Andy Wellings, 2004

 Introduction I
 An advantage of using a high-level language is that it relieves
the programmer of the burden of dealing with many of the low-
level resource allocation issues
 Issues such as assigning variables to registers or memory
locations, allocating and freeing memory for dynamic data
structures, etc., all detract the programmer from the task at hand
 Languages like Java remove many of these troublesome worries
and provide high-level abstract models that the programmer can
use

© Andy Wellings, 2004

 Introduction II
 For real-time/embedded systems programming
there is a conflict
 Use of high-level abstractions aid in the software
engineering of the application
 Yet embedded and real-time systems often only have
limited resources (time and space) and these must be
carefully managed
 Nowhere is this conflict more apparent than in
the area of memory management
 Embedded systems usually have a limited
amount of memory available; this is because of
cost, size, power, weight or other constraints
imposed by the overall system requirements
 It may be necessary to control how this
memory is allocated so that it can be used
effectively
© Andy Wellings, 2004
 Stack versus Heap
Memory
 The run-time system of most languages provide
two data structures to help manage dynamic
memory: the stack and the heap
 In Java, the stack is typically used for storing
variables of basic data types (such as int, boolean
and reference variables) which are local to a method
 All objects, which are created from class definitions,
are stored on the heap and the language requires
garbage collection (GC) for an effective JVM
implementation
 Much work has been done on real-time GC, yet
there is still a reluctance to rely on it in time-critical
systems
© Andy Wellings, 2004
 Real-time and Garbage
Collection
 GC may be performed either when the heap is full or
incrementally (asynchronous garbage collection)
 Running the garbage collector may have a significant impact
on the response time of a time-critical thread
 Consider a time-critical periodic thread which has had all its
objects pre-allocated
 Even though it may have a higher priority than a non time-
critical thread and will not require any new memory, it may
still be delayed if it preempts the non time-critical thread
when garbage collection has been initiated by an action of
that thread
 In this instance, it is not safe for the time-critical thread to
execute until garbage collection has finished (particularly if
memory compaction is taking place)

© Andy Wellings, 2004

 The RTSJ and Memory
Management
 The RTSJ recognizes that it is necessary to allow
memory management which is not affected by the
problems of garbage collection
 It does this via the introduction of immortal and
scoped memory areas
 These are areas of memory which are logically
outside of the heap and, therefore, are not subject
to garbage collection

 If a schedulable object is active in a memory area,

all calls to new create the object in that memory
area

© Andy Wellings, 2004

 The Basic Model
 RTSJ provides two alternatives to using the heap:
immortal memory and scoped memory
 The memory associated with objects allocated in
immortal memory is never subject to garbage collection
and is never released during the lifetime of the
application
 Objects allocated in scoped memory have a well-defined
life time
 Schedulable objects may enter and leave a scoped
memory area
 Whilst they are executing within that area, all memory
allocations are performed from the scoped memory
 When there are no schedulable objects active inside a
scoped memory area, the allocated memory is reclaimed

© Andy Wellings, 2004

 Memory Areas I
public abstract class MemoryArea {
protected MemoryArea(long sizeInBytes);
protected MemoryArea(long sizeInBytes, Runnable logic);
...
// methods
public void enter();
// Associate this memory area to the current
// schedulable object for the duration of the
// logic.run method passed as a parameter to
// the constructor
public void enter(Runnable logic);
// Associate this memory area to the current
// schedulable object for the duration of the
// logic.run method passed as a parameter

© Andy Wellings, 2004

 Memory Areas II

public static MemoryArea getMemoryArea(Object object);

// Get the memory area associated with the object
public long memoryConsumed();
// Returns the number of bytes consumed
public long memoryRemaining();
// Returns the number of bytes remaining
public long size();
// Returns the current size of the memory area
...
}

© Andy Wellings, 2004

 Immortal Memory
public final class ImmortalMemory extends MemoryArea
{
public static ImmortalMemory instance();
}

 There is only one ImmortalMemory area, hence the class is

defined as final and has only one additional method
(instance) which will return a reference to the immortal
memory area
 Immortal memory is shared among all threads in an
application
 Note, there is no public constructor for this class. Hence, the
size of the immortal memory is fixed by the real-time JVM

© Andy Wellings, 2004

 Allocating Objects in Immortal
Memory

 The simplest method for allocating objects in

immortal memory is to use the enter method in
the MemoryArea class and pass an object
implementing the Runnable interface

ImmortalMemory.instance().enter(new Runnable()
{
public void run() {
// any memory allocation performed here
// using the allocator will occur in
// Immortal memory
}
} ); see Introduction notes about
anonymous inner classes

© Andy Wellings, 2004

 Warning

It should be stressed that although all memory allocated by

the above run method will occur from immortal memory, any
memory needed by the object implementing the run method
will be allocated from the current memory area at the time of
the call to enter

In this case, some small amount of memory will still be

allocated by the virtual machine in order to implement the
object

© Andy Wellings, 2004

 Scope Memory Areas

public abstract class ScopedMemory extends MemoryArea {

// constructors
public ScopedMemory(long size);
public ScopedMemory(long size, Runnable logic);
...
// methods
public void enter();
public void enter(Runnable logic);
public long getMaximumSize();
...
}

© Andy Wellings, 2004

 Linear Time Memory
package javax.realtime;
public class LTMemory extends ScopedMemory {
//constructors
public LTMemory(long initialSizeInBytes,
long maxSizeInBytes);
public LTMemory(long initialSizeInBytes,
long maxSizeInBytes, Runnable logic);
...
// methods
public int getMaximumSize();
}

Similarly for VTMemory: variable time memory

© Andy Wellings, 2004

 Note

Linear time refers to the time it takes to create

an object in the memory, NOT, the time it
takes to run the constructor

© Andy Wellings, 2004

 Reference Counts
 Each scoped memory object has a reference count
which indicates the number of times the scope has
been entered
 When that reference count goes from 1 to 0, the
memory allocated in the scoped memory area can be
reclaimed (after running any finalization code
associated with the allocated objects)

© Andy Wellings, 2004

 Example: Scoped Memory
 Consider a class that encapsulates a large table
which contains (two by two) matrices
 The match method takes a two by two matrix and
performs the dot product of this with every entry in
the table
 It then counts the number of results for which the
dot product is the unity matrix

© Andy Wellings, 2004

 Matrix
public class MatrixExample {
public MatrixExample(int Size)
{ /* initialize table */ }
public int match(final int with[][])
{ /* check if “with” is in the table */ }
private int[][] dotProduct(int[][] a, int [][] b)
{ /* calculate dot product return result */ }

private boolean equals(int[] [] a, int[] [] b)

{ /* returns true if the matrices are equal */ }
private int [][][] table; // 2 by 2 matrices
private int [][] unity = {{1,1},{1,1}};
}

© Andy Wellings, 2004

 Match Method: with GC
public int match(final int with[][]) {
int found = 0;
for(int i=0; i < table.length; i++) {
int[][] product = dotProduct(table[i], with);
if(equals(product, unity)) found++;
}
return found;
}

 Each time around the loop, a call to dotProduct is

made which creates and returns a new matrix object
 This object is then compared to the unity matrix
 After this comparison, the matrix object is available
for garbage collection

© Andy Wellings, 2004

 Match Method: LTMemory
public int match(final int with[][]) {
// first attempt
LTMemory myMem = new LTMemory(1000, 5000);
int found = 0;
for(int i=0; i < table.length; i++) {
myMem.enter(new Runnable()
{
public void run() {
int[][] product = dotProduct(table[i], with);
if(equals(product, unity)) found++;
}
});
}
}
return found;
}

© Andy Wellings, 2004

 Problems
 The accessibility of the for loop parameter i; the
only local parameters that can be accessed from
within a class nested within a method are those
that are final. i and found are not final
 To solve this problem it is necessary to create a
new final variable, j, inside the loop which contains
the current value of i
 The variable found must be moved to be local to
the class and initialized to 0 on each call of the
match

© Andy Wellings, 2004

 Problems Continued
 The anonymous class is a subclass of Object not
the outer class MatrixExample
 Consequently, the default equals method is the one
in Object and a compilation error occurs
 This can be circumvented by naming the method
explicitly

© Andy Wellings, 2004

 Matrix Version 2
public class MatrixExample {
public MatrixExample(int Size)
{ /* initialize table */ }
public int match(final int with[][])
{ /* check if “with” is in the table */ }
private int[][] dotProduct(int[][] a, int [][] b)
{ /* calculate dot product return result */ }
private boolean equals(int[] [] a, int[] [] b)
{ /* returns true if the matrices are equal */ }
private int [][][] table; // 2 by 2 matrices
private int [][] unity = {{1,1},{1,1}};
public int found = 0;
private LTMemory myMem;
}
© Andy Wellings, 2004
 Match Version 2
public int match(final int with[][]) {
found = 0;
for(int i=0; i < table.length; i++) {
final int j = i;
// myMem now declared at the class level
myMem.enter(new Runnable()
{
public void run() {
int[][] product = dotProduct(table[j], with);
if(MatrixExample.this.equals(product, unity))
found++;
}
});
}
return found;
}

© Andy Wellings, 2004

 Problem
 This approach now reclaims the temporary memory
every time the enter method terminates
 However the creating of the anonymous class will
still use memory in the surrounding memory area
 In this case, there will be memory for a private
copy of the j variable and a private reference to the
with array (this is how the compiler implements
the access to the method’s data)
 As well as these, there will be some other memory
allocated for implementing the object
 Although this memory cannot be entirely
eliminated, it can be significantly reduced by
creating an object from a named inner class and
reusing that object
© Andy Wellings, 2004
 Matrix Final Version
public class MatrixExample
{
...
// constructor contains produce = new Product();

private class Product implements Runnable {

int j;
int withMatrix[][];
int found = 0;
public void run() {
int[][] product = dotProduct(table[j],
withMatrix);
if(matrixEquals(product, unity)) found++;
}
}
...
}
© Andy Wellings, 2004
 Match Final Version
public int match(final int with[][]) {
produce.found = 0;
for(int i=0; i < table.length; i++) {
produce.j = i;
produce.withMatrix = with;
myMem.enter(produce);
}
return produce.found;
}

 With this solution, there is just the initial cost of creating the
produce object (performed in the constructor of
MatrixExample)
 Note that the only way to pass parameters to the run
method is via setting attributes of the object (in this case
directly)

© Andy Wellings, 2004

 Size Estimator
package javax.realtime;
public final class SizeEstimator {
// constructor
public SizeEstimator();
//methods
public long getEstimate();
public void reserve(java.lang.Class c, int n);
public void reserve(SizeEstimator s);
public void reserve(SizeEstimator s, int n);
}

 Allows the size of a Java object to be estimated

 Again, size is the object itself, it does not include an objects
created during the constructor

© Andy Wellings, 2004

 Example

{
SizeEstimator s = new SizeEstimator();

s.reserve(javax.realtime.PriorityParameters.class, 1);
System.out.println(“size of PriorityParameters is “
+s.getEstimate());
}

© Andy Wellings, 2004

 Summary
 The lack of confidence in real-time garbage collection
is one of the main inhibitors to the widespread use of
Java in real-time and embedded systems
 The RTSJ has introduced an alternative (additional)
memory management facility based on the concept
of memory areas
 There are two types on non-heap memory areas
 a singleton immortal memory which is never subject to
garbage collection
 scoped memory in to which schedulable objects can enter
and leave. When there are no schedulable objects active in a
scoped memory area, all the objects are destroyed and their
memory reclaimed.

© Andy Wellings, 2004

 Further Reading and
Exercises
 Scoped memory areas are one of the most
controversial aspects of the RTSJ - look on the web
to find out why.

© Andy Wellings, 2004