Your SlideShare is downloading. ×
Remote Memory Areas for distributed real-time Java
Upcoming SlideShare
Loading in...5
×

Thanks for flagging this SlideShare!

Oops! An error has occurred.

×

Introducing the official SlideShare app

Stunning, full-screen experience for iPhone and Android

Text the download link to your phone

Standard text messaging rates apply

Remote Memory Areas for distributed real-time Java

269
views

Published on

Published in: Technology, Education

0 Comments
0 Likes
Statistics
Notes
  • Be the first to comment

  • Be the first to like this

No Downloads
Views
Total Views
269
On Slideshare
0
From Embeds
0
Number of Embeds
1
Actions
Shares
0
Downloads
1
Comments
0
Likes
0
Embeds 0
No embeds

Report content
Flagged as inappropriate Flag as inappropriate
Flag as inappropriate

Select your reason for flagging this presentation as inappropriate.

Cancel
No notes for slide

Transcript

  • 1. Pablo Basanta Val& Marisol García 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 Java’s 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 RTSJ’s 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<1024; i++){ 05: samples[i]=normalize(samples, i); 06: } 07:}
  • 10. Heap remote memory area 00:class RemoteHeapMemory implements 01: RemoteMemoryArea, Schedulable{ 02: public RemoteHeapMemory() { 03: } 04: public Schedulable enterSchedulable(Schedulable ss) 05: { Schedulable th=set_thread_parameters(ss); 06: ss.run(); 07: restore_thead_parameters(th); 08: return ss; 09: } 10: public void enterAsyncSchedulable (Schedulable ss) 11: { RealtimeThread th= threadpool.getThread(); 12: set_thread_parameters(ss); 13: th.runAsync(ss); 12: return; 13: } ... 14:}
  • 11. No-GC Remote Memory Area Implementation Objects allocated in a LTMemory Instance from the LTMemoryAreaPool Objects allocated in a LTMemory Instance from the LTMemoryAreaPool. 00:class RemoteLTMemoryAreaPool implements 01: RemoteMemoryArea, Schedulable{ 02: public RemoteLTMemoryAreaPool(int ltmemory_size, 03: int element_size) { 04: ltmpool= new LTMemoryAreaPool(size,element_size); 05: } 06: public Schedulable enterSchedulable(Schedulable ss) 07: { Schedulable th=set_thread_parameters(ss); 08: ss.run(); 09: restore_thead_parameters(th); 10: return ss; 11: } 11: public void enterAsyncSchedulable (Schedulable ss) 12: { threadpool.getThread().runAsync(ss); 13: return; 14: } ... 15:}
  • 12. Developer Perspective  An industrial inspired use- case  A simple distributed application for control that i) reads data, ii) processes these data, iii) and stores the data End-to-end application deadline ProcessDataReadData WriteOutput input RTSJ-JVM Server1 RTSJ-JVM Server2 RTSJ-JVM Server3 outputprocess SRC RMA PROC RMA DEST RMA RMI RMI RMI RMI Registry SRC RMA PROC RMA DEST RMA RTSJ-JVM Client RMI enteSch enterSch enterSch Step 1 Step 2 Step 3 ThreeStepsApp
  • 13. The application in a single Runnable class  Three is a internal counter (scount) that decides in which step is the application  All public and serializable attributes are transferred from a to the server  (namely: 05: array 04: local 02: scount ) 00: public class ThreeStepsApp 01: extends Schedulable, Serializable{ 02: int scount=0; 03: ... 04: boolean local=true; 05: long[] array= null; 06: ThreeStepsApp(...){ 07: array=new long[1024]; 08: } 09: public void run(){ 10: scount ++; 11: switch(scount) 13: { 14: case 1: //First execution 15: for (int i=0; i<1024; i++) 16: { array[i]=input(); 17: } 18: break; 19: case 2: //Second execution 20: for (int i=0; i<1024; i++) 21: { array[i]=process(array[i]); 22: } 23: case 3: 24: output(array[1023]); 25: break; 26: } 27: private trace(long){ … } 28: }
  • 14. Running the example  Periodically, it runs the three steps application  At a 32 priority which is propagated from client to servers 01:new RealtimeThread(){ 02: public void run(){ 03: setSchedulingParameters 04: (PriorityParamters(32)); 05: ThreeStepsApp tsc= new ThreeStepsApp(); 06: RemoteMemoryArea src=lookupSrc(); 07: RemoteMemoryArea proc=lookupDest(); 08: RemoteMemoryArea dest=lookupRemoteHeap(); 09: tsc.setSchedulingParameters 10: (PriorityParamters(8)); 11: do{ 12: tsc=(TestSchedulable3)src.enterSchedulable(tsc); 12: tsc=(TestSchedulable3)proc.enterSchedulable(tsc); 13: tsc=(TestSchedulable3)dest.enterSchedulable(tsc); 14: waitForTheNextPeriod(); 15: }while(true); 16:}.start();
  • 15. Empirical evaluation  Derived from the previous application  Control benchmark application  The extension  + RMAs  + Lightweight RT-RMI Extensions  Software stack  Oracle’ JRTS.  Two virtual machines running on an 800 MHz processor+100 Mbps Ethernet.  The underlying kernel is a real-time Linux 3.0 rt-patched kernel on a Debian 6.0 distribution RT-RMI extensions Oracle JRTS Debian 3.0 rt-patch Intel 800 Mhz -100 Mbits RMAs Extension Control Application
  • 16. Empirical evaluation results  Parametric benchmark  Array sizes from  100 bytes,  to  1E05 bytes  Not much overhead when compared against traditional RMI  Similar results  Overhead reduces with high data volumes  From [15% to less than 5%] in 100 bytes to 1E5 bytes
  • 17. Conclusions  A new way of performing remote communications was proposed  Remote Memory Area (RMA)s based on runnable objects  More low-level (& flexible than traditional remote invocations)  RMAs was evaluated with a distributed control applications  With an use case three steps application  RMAs empirical evidence showed that  They do not produce too much overhead
  • 18. Ongoing Work  Security issues:  Safe execution of runnable objects in servers  Merging the model with other architectural models  With support from distributable threads  As a means to provide real-time reconfiguration
  • 19. Any questions??? http://www.it.uc3m.es/drequiem/