© Andy Wellings, 2004 Roadmap  Introduction  Concurrent Programming  Communication and Synchronization  Completing the Java Model  Overview of the RTSJ  Memory Management  An overview of MemoryAreas  An example of Scoped Memory Usage  How to estimating the size of objects  Continued …  Clocks and Time  Scheduling and Schedulable Objects  Asynchronous Events and Handlers  Real-Time Threads  Asynchronous Transfer of Control  Resource Control  Schedulability Analysis  Conclusions

© Andy Wellings, 2004 Memory Management Lecture aims:  To explain the RTSJ assignment Rules  To illustrate the single parent rule  To consider the sharing of memory areas between Schedulable objects

© Andy Wellings, 2004 Memory Assignment Rules  In the RTSJ there are four types of memory  heap memory: collected by the garbage collector  local variables (stack memory): collected automatically when methods exit  immortal memory: never collected  scoped memory: available for collection when the associated reference count equals zero  Given the different collection mechanism, it is necessary to impose some restrictions on assignments between the different types of memory  Otherwise dangling references may occur  A dangling reference is a references to an object that has been collected when scoped memory is reclaimed

© Andy Wellings, 2004 Dangling Reference Example  A, has been created in a scoped memory region  A reference to that object has been stored in object, B, which resides in the heap  The lifetime of a scoped memory is controlled by its reference count

© Andy Wellings, 2004 The Reference Count The reference count of a scoped memory area is the count of the number of active calls (explicit or implicit) to its enter method. It is NOT a count of the number of objects that have references to the objects allocated in the scoped memory. The reference to object, A, from object, B, becoming invalid (dangling) when object A’s memory area is reclaimed. There would be no way to detect this invalid reference, so the safety of the Java program would be compromised.

© Andy Wellings, 2004 Memory Assignment Rules generally allowedallowed Local Variable allowed is to same scope or outer scope forbidden if to an inner scope allowed Scoped Memory forbiddenallowed Immortal Memory forbiddenallowed Heap Memory To Scoped Memory To Immortal Memory To Heap MemoryFrom Memory Area

© Andy Wellings, 2004 Note  If the program violates the assignment rules, the unchecked exception IllegalAssignmentError is thrown  One of the requirements for the RTSJ was that there should be no changes to the Java language and that existing compilers can be used to compile RTSJ programs  These rules must be enforced on every assignment statement at run-time by the real-time JVM  An RTSJ-aware compiler may be able to undertake some static analysis in order to reduce this burden  Alternatively, checks may be performed at class loading time

© Andy Wellings, 2004 Nested Memory Areas  The real-time JVM will need to keep track of the currently active memory areas of each schedulable object  One way this can be achieved is via a stack  Every time a schedulable object enters a memory area, the identity of that area is pushed onto the stack  When it leaves the memory area, the identity is popped off the stack stack grows upwards

© Andy Wellings, 2004 Implementation of Assignment Rules I  The stack can be used to check for invalid memory assignment to and from scoped memory areas  Creating a reference from an object in one scoped memory area to an object in another scoped memory area below the first area in the stack is allowed.  Creating a reference from an object in one scoped memory area to an object in another scoped memory area above the first area in the stack is forbidden

© Andy Wellings, 2004 Implementation of Assignment Rules II  If O1 is in ScopedB and O2 is in ScopedA  O1.O2Ref = O2 is ALLOWED  O2.O1Ref = O1 is DISALLOWED The memory assignment rules by themselves are still inadequate to avoid the dangling reference problem!

© Andy Wellings, 2004 Consider  A schedulable object enters the same memory area twice  Now an object could be created in ScopedA which references an object in ScopedB  However, when the current ScopedA memory is exited, the reference count for that area is still greater than zero and so its objects are not reclaimed  Now when ScopedB is exited, it objects are reclaimed and consequently, the object in ScopedA is left with a dangling reference

© Andy Wellings, 2004 The Single Parent Rule  To avoid this problem, the RTSJ requires that each scoped memory area has a single parent  The parent of an active scoped memory area is  If the memory is the first scoped area on the stack, its parent is termed the primordial scope area  For all other scoped memory areas, the parent is the first scoped area below it on the stack Violates the single parent rule, therefore ScopedCycleException is thrown

© Andy Wellings, 2004 Moving Between Memory Areas  As it is not possible to re-enter an active scoped memory area, it is necessary to provide alternative mechanisms for moving between active memory areas public abstract class MemoryArea {... public void executeInArea(Runnable logic); public Object newArray(Class type, int number) throws various_exceptions; public Object newInstance(Class type) throws various_exceptions; public Object newInstance( java.lang.reflect.Constructor c, Object[] args) throws various_exceptions; }

© Andy Wellings, 2004 Cactus Stack Now Needed heap ScopedA ScopedB current Immortal (a) Initial stack heap ScopedA ScopedB current Immortal (b) During, ScopedA.executeInArea(…) heap ScopedA ScopedB current ImmortalScopedC (c) During, ScopedC.enter(…)

© Andy Wellings, 2004 Important Note  A call to executeInArea with a parameter of the heap (or immortal) memory, results in a new memory stack being created, with the heap (or immortal) memory area at its base.

© Andy Wellings, 2004 Sharing Memory Areas  Multiple schedulable objects can access the same memory areas  Consequently, the cactus stacks for each schedulable objects are linked together  Here, two real-time threads ( ThreadA and ThreadB ) have active scoped memory stacks. ThreadAThreadB

© Andy Wellings, 2004 Sharing Memory Areas  Suppose that ThreadA wishes to enter ScopedE ; it cannot do so directly because ScopedE is already active and has a parent of ScopedD  To gain access to ScopedE, ThreadA must first move to ScopedA (using executeInArea ), then enter ScopedD followed by ScopedE ThreadA ThreadB

© Andy Wellings, 2004 Inheritance of Stack I  When a schedulable object is created, its initial memory area stack can be set; for example, the RealtimeThread class package javax.realtime; public class RealtimeThread extends Thread implements Schedulable { // constructors public RealtimeThread(SchedulingParameters scheduling, ReleaseParameters release, MemoryParameters memory, MemoryArea area, ProcessingGroupParameters group, Runnable logic);... }

© Andy Wellings, 2004 Inheritance of Stack II  The stack of a created schedulable object is determined by the value of the initial memory area (the area parameter) and the currently active memory area  If current area is the heap and  the initial memory area is the heap, the new stack contains only the heap memory area  the initial memory area is not the heap, the new stack contains the heap and the initial memory area  If current area is the immortal memory area and  the initial memory area is the immortal memory area, the new stack contains only the immortal memory area  the initial memory area is not the immortal memory area, the new stack contains the immortal memory area and the initial memory area

© Andy Wellings, 2004 Inheritance of Stack III  If the current area is a scoped memory area and the initial memory area is the currently active memory area (or null)  the new stack is the parent’s stack up to and including the current memory area  If the current area is a scoped memory area and the initial memory area is not the currently active memory area  the new stack is the parent’s stack up to and including the current memory area, plus the initial memory area

© Andy Wellings, 2004 Inheritance of Stack Example I ScopeE ScopeD ScopeC ScopeB ScopeA Heap Immortal Parent Stack current memory area If initial memory area is the heap what is the child’s stack?

© Andy Wellings, 2004 Inheritance of Stack Example II ScopeE ScopeD ScopeC ScopeB ScopeA Heap Immortal Parent Stack current memory area If initial memory area is the heap what is the child’s stack?

© Andy Wellings, 2004 Inheritance of Stack Example III ScopeE ScopeD ScopeC ScopeB ScopeA Heap Immortal Parent Stack current memory area If initial memory area is the ScopeF what is the child’s stack?

© Andy Wellings, 2004 Inheritance of Stack Example IV ScopeE ScopeD ScopeC ScopeB ScopeA Heap Immortal Parent Stack current memory area If initial memory area is the scopeA what is the child’s stack?

© Andy Wellings, 2004 Inheritance of Stack Example V ScopeE ScopeD ScopeC ScopeB ScopeA Heap Immortal Parent Stack current memory area If initial memory area is the heap what is the child’s stack? ScopeG ScopeF

© Andy Wellings, 2004 Entering and Joining Scoped Memory Areas  Scoped memory areas can be used in one of two modes of operation: cooperatively or competitively  In cooperative use, the schedulable objects aim to be active in a scoped memory area simultaneously  they use the area to communicate shared objects  when they leave, the memory is reclaimed  In competitive use, the goal is to make the most efficient use of memory  the schedulable objects are trying to take their memory from the same area but are not using the area for the communication  here, it is usually required for only one schedulable to be active in the memory area at one time  the intention is that the memory can be reclaimed when each of the schedulable objects leave the area

© Andy Wellings, 2004 Competitive Use  To ensure that the area becomes inactive use: package javax.realtime; public abstract class ScopedMemory extends MemoryArea {... public int getReferenceCount(); public void join() throws InterruptedException; public void join(HighResolutionTime time) throws InterruptedException; public void joinAndEnter() throws InterruptedException; public void joinAndEnter(HighResolutionTime time) throws InterruptedException; public void joinAndEnter(java.lang.Runnable logic) throws InterruptedException; public void joinAndEnter(java.lang.Runnable logic, HighResolutionTime time) throws InterruptedException;... }

© Andy Wellings, 2004 Join and Enter Issues  If timeout expires, the memory area is entered  It is difficult to know if the timeout did expire

© 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 additional memory management facility based on the concept of memory areas  There are two types on non-heap memory areas  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.  Due to the variety of memory areas, the RTSJ has strict assignment rules between them in order to ensure that dangling references do not occur

© Andy Wellings, 2004 Further Reading and Exercises  Do the Accessing Memory Areas Exercise