© 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  Assignment rules  Sharing scoped memory areas  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 motivate the need for portal objects and provide an example of their use  To consider the real-time issues of scoped memory areas

© Andy Wellings, 2004 Recall from previous lecture  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  only one schedulable is 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 Portals I  For cooperative sharing where there is no other relationship between the schedulable objects, how can schedulable objects share objects created in the scoped memory area?  To share an object requires each schedulable object to have a reference to that object  A reference to an object can only be stored in an object in the same scoped area or in an object in a nested scoped area  It cannot be stored in the immortal or heaped memory area  Consequently, unless there is some relationship between the schedulable objects, one schedulable object cannot pass a reference to an object it has just created to another schedulable object

© Andy Wellings, 2004 Portals II  Portals solve this problem; each scoped memory area can have one object which can act as a gateway into that memory area  Schedulable objects can use this mechanism to facilitate communication package javax.realtime; public abstract class ScopedMemory extends MemoryArea {... public Object getPortal(); public void setPortal(Object o); }

© Andy Wellings, 2004 Portal Example I  Consider, the example of an object which controls the firing of a missile  For the missile to be launched two independent real-time threads must call its fire method each with its own authorization code import javax.realtime.*; public class FireMissile { public FireMissile(); public boolean fire1(final String authorizationCode); public boolean fire2(final String authorizationCode); }

© Andy Wellings, 2004 Portal Example II  The two threads call fire1 and fire2 respectively  Whichever calls in first has it authorization code checked and is held until the other thread calls its fire method  If both threads have valid authorization codes, the missile is fired and methods returns true  If either threads’ authorization code fails, the missile is not fired and the fire methods return false.  In order to implement the fire methods, assume that objects need to be created in order to check the authorization public class Decrypt { public boolean confirm(String code) { /* check authorization */ } }

© Andy Wellings, 2004 Portal Example III  To obtain the required synchronization, the two real-time threads must communicate  The threads call wait indicating whether they wish to fire. If both pass true, wait returns true public class BarrierWithParameter { public BarrierWithParameter(int participants); public synchronized boolean wait(boolean go); } // see notes for implementation

© Andy Wellings, 2004 Portal Example IV  The goal is to implement the FireMissile class without using extra memory other than that required to instantiate the class  All memory needed by the fire methods should be created in scoped memory which can be reclaimed when the fire methods are inactive  In order to implement the required firing algorithm, the class needs two Decrypt objects and one BarrierWithParameter object

© Andy Wellings, 2004 Portal Example V import javax.realtime.*; public class FireMissile { public FireMissile() {... SizeEstimator s = new SizeEstimator(); s.reserve(Decrypt.class, 2); s.reserve(BarrierWithParameter.class, 1); shared = new LTMemory(s.getEstimate(), s.getEstimate()); } private LTMemory shared;... }

© Andy Wellings, 2004 Portal Example VI  Both threads need to access a BarrierWithParameter object, they therefore must enter into the same scoped memory area  The shared memory area must have a single parent  As this class is unaware of the scoped stacks of the calling threads, it needs to create new scoped memory stacks  It does this by using the executeInArea method to enter into immortal memory  The associate run method can now enter into the scoped memory area. The alternative approach would be to assume the calling threads have empty (or the same) scope stacks

© Andy Wellings, 2004 Portal Example VII import javax.realtime.*; public class FireMissile { public FireMissile() { fireController1 = new FireAction(); fireController2 = new FireAction(); immortalController1 = new ImmortalAction(); immortalController2 = new ImmortalAction(); SizeEstimator s = new SizeEstimator(); s.reserve(Decrypt.class,2); s.reserve(BarrierWithParameter.class, 1); shared = new LTMemory(s.getEstimate(), s.getEstimate()); }... }

© Andy Wellings, 2004 Portal Example VIII public class FireMissile {... class FireAction implements Runnable { String authorization; boolean result; public void run() { /* coordinate the firing of the missile */} } class ImmortalAction implements Runnable { FireAction fireController; public void run() { shared.enter(fireController); }

© Andy Wellings, 2004 Portal Example IX

© Andy Wellings, 2004 Portal Example X public class FireMissile {... public boolean fire1(final String authorizationCode) { try { immortalController1.fireController = fireController1; fireController1.authorization = authorizationCode; ImmortalMemory.instance().executeInArea( immortalController1); return fireController1.result; } catch (InaccessibleMemoryArea ma) {} } // similarly for fire2 private LTMemory shared; private FireAction fireController1, fireController2; private ImmortalAction immortalController1, immortalController2; }

© Andy Wellings, 2004 Portal Example XI  Once inside the scoped memory area, the required objects can be created.  However, a problem occurs with the shared BarrierWithParameter object.  In order for both threads to access the BarrierWithParameter method they both must have a reference to it  Usually, the reference would be stored in a private reference declared at the class level  However, this is not possible in this case, as it would break the RTSJ assignment rules as the BarrierWithParameter object is in an inner scope  Hence, use portals

© Andy Wellings, 2004 Portal Example XII  The first thread to arrive attempts to obtain the portal object for the shared memory region  This is null, so it creates the BarrierWithParameter object and sets it up as the portal object  The next thread to arrive can then obtain the required reference  When both threads leave the shared memory area, all the memory is reclaimed  However, there is a race condition between checking for the existence of the portal object and setting a newly created one  Consequently, a lock is needed. One lock that is available at this stage is the lock associated with the scoped memory object itself!

© Andy Wellings, 2004 Portal Example XIII class FireAction implements Runnable { String authorization; boolean result; public void run() { BarrierWithParameter sync; Decrypt check = new Decrypt(); boolean confirmed = check.confirm(authorization); synchronized(RealtimeThread.getCurrentMemoryArea()) { sync = (BarrierWithParameter)shared.getPortal(); if(sync == null) { sync = new BarriewWithParameter(2); shared.setPortal(sync); } } result = sync.wait(confirmed); }

© Andy Wellings, 2004 Portal Example XIV

© Andy Wellings, 2004 Using Scoped Memory Areas  When a class is written which needs some temporary memory should it take responsibility for creating and entering a scoped memory area?  It is necessary to determine if the class may be used concurrently  If the class targets sequential access and it is used concurrently with active memory areas, a ScopedCycleException may be thrown  The client schedulable objects must either ensure that the scoped memory stack is empty or, ensure that all clients call with the same stack  Clients need to have details of when a class is using scoped memory areas  If the class targets concurrent access:  it must either assume clients have the same scoped memory stacks, or it must “execute in” a heap or an immortal area first (to create new stacks)  if it chooses the heap, the class cannot be used by a no-heap client;  if it chooses immortal memory, named inner classes must be used — otherwise every time it creates an object from an anonymous class, some memory will be created in immortal memory and this will not be reclaimed  It is perhaps easier to manage the problems at the thread level rather than the object level?

© Andy Wellings, 2004 Real-Time Issues I  Entry to scoped memory  On entry into a scoped memory region, a schedulable object may be blocked if it uses one of the join or joinAndEnter methods  The duration of this blocking may be difficult to bound (unless timeouts are used, but these have their own problems)  If the schedulable objects using the scoped memory do not themselves block when they have entered the scoped memory region, the blocking time will be the maximum time that lower priority schedulable objects take to execute the associated run method  When a schedulable object attempts to enter into a previously active scoped memory area, it may also have to wait for the memory to be reclaimed

© Andy Wellings, 2004 Real-Time Issues II  Predictable scoped memory allocation  Memory allocation in a scoped memory should be predictable from the details of the implementation and the objects being created  It will consist of two components: the time taken to allocate the space for the objects (which will be proportional to their sizes, for LTMemory ), and the time taken to execute the constructors for the objects created

© Andy Wellings, 2004 Real-Time Issues III  Exit from scoped memory  The RTSJ gives a great deal of freedom on when the memory used in a scoped memory area is reclaimed  An implementation might decide to reclaim the memory immediately the reference count becomes zero or sometime after it becomes zero, but no later than when a new schedulable object wishes to enter it  Hence, a schedulable object on one occasion may leave the scoped memory and suffer no impact; on another occasion, it is the last object to leave and reclamation occurs immediately; alternatively it may suffer when it first enters the scope

© Andy Wellings, 2004 Real-Time Issues IV  Object finalization  Whenever scoped memory is reclaimed, the objects that have been created must have their finalization code executed before reclamation  The time for this to occur must be accounted for in any analysis.  Garbage collector scans  The impact, if any, of the garbage collector scanning the scoped memory area looking for heap references when those memory areas are being reclaimed concurrently

© Andy Wellings, 2004 Summary  Portal objects can be used to facilitate communication between schedulable objects using the same scoped memory area  There is little doubt that non-heap memory management is one of the most complicated areas of the RTSJ, and one that has a major impact on the overheads of the virtual machine

© Andy Wellings, 2004 Further Reading and Exercises  Look up Real-time Garbage Collection and consider the advantages/disadvantages (from the programmer ’ s perspective) of a system with real-time garbage collection and a system with scoped memory