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.
From Event to Action: Accelerate Your Decision Making with Real-Time Automation
Remote Memory Areas for distributed real-time Java
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:}
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