1. Pablo Basanta Val& Marisol Garca Valls DREQUIEM Lab. Universidad Carlos III de Madrid http://www.it.uc3m.es/drequiem/ Extending Distributed Real- Time Java with Remote Memory Areas

2. Outline Context {Real-Time Java}Context Distributed real-time Java Contribution:Remote Memory Areas Abstraction Overview Developer perspective Empirical Evaluation Conclusion and Future Work 3. Introduction Industrial applications may benefit from having high- level programming abstractions E.g. MDA, MDE, Java, real-time Java Benefits Reduced development time Kind of applications developed More success in producing final products/developments Drawbacks These technologies are also source of their own issues Less tested technology Lower execution performance Specific research niches 4. Real-time Java technology Centralized efforts Leading effort RTSJ (Real-Time Specification for Java) has An specification , several implementations ready to be used An high-integrity specification for Java is ongoing (SCSJ) Safety Critical Specification for Java A specification and partial implementation Distributed efforts Leading effort DRTSJ (Distributed Real-Time Specification for Java) is upcoming More immature than RTSJ: No specification for DRTSJ, Only partial prototype implementations for RMI (Java Remote Method Invocation). 5. The contribution in a nutshell Most approaches for distributed real-time Java are based on remote invocations included in Javas RMI Well-known distributed object model This paper explores another approach that may complement the RMI previous model: Remote Memory Areas An RMA is generic set of mechanism that allows execution of remote code in a remote node Technical approach: To transform RTSJs MemoryAreainto remote objects DRTSJ may benefit from RMAs. 6. Remote Memory Areas Based on the semantics of the enter method of RTSJ This method changes the allocation context of a thread when calling the method RMAs extend the semantic to a distributed system Applications invoke on remote memory areas API of a Memory Area in RTSJ 01: public abstract class MemoryArea{ 02: MemoryArea(long size) 03: void enter(Runnable logic) 04: void executeInArea(Runnable logic) 05: Object newInstance(); 06: } Local JVM Local JVM Remote JVM enter( ) enter( ) enter( ) (1) (2) Local invocation Remote invocation ss.run(); client server Runnable Schedulable 7. Remote Memory Areas: Interface Based on the semantics of the enter method of RTSJ This method changes the allocation context of a thread when calling the method RMAs extend the semantic to a distributed system Applications may invoke on remote memory areas Remote Memory Area interface 01: RemoteMemoryArea extends java.rmi.Remote{ 02: Schedulable enterSchedulable(Schedulable s) 03: throws RemoteException; 04: void enterAsyncSchedulable(Schedulable s) 05: throws RemoteException; 06:} 8. Remote Memory Areas: Issues Relationship with CPU Server defined Each remote objet has its own scheduling information Client-propagated Scheduling information Mainly Priorities Relationship with the garbage collector Heap dependant on a Interaction with the GC No-heap behavior in applications that do want No interaction with the GC Very specific programming model (NhRo-paradigm) 9. Type of application with RMAs Applications are defined as runnable objects with scheduling information Each server Changes its scheduling parameters Executes the run method Restores its previous state 01: public class NormalizerFilter 02: implements Runnable, Serializable, Schedulable{ 03: long samples[1024]; //Input and Output 03: public void run(){ 04: for (int=0;i