This document proposes an approach called Remote Memory Areas (RMAs) to extend Distributed Real-Time Java. RMAs allow execution of remote code in a remote node by transforming the MemoryArea abstraction in Real-Time Specification for Java into remote objects. The paper describes the RMA abstraction and interface, issues in its implementation, example applications using RMAs, and an empirical evaluation showing RMAs introduce little overhead compared to traditional remote invocations. Ongoing work includes addressing security issues and merging RMAs with other distributed models.

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/