No Heap Remote Objects for Distributed real-time Java
1. No Heap Remote Objects for Distributed
Real-Time Java
Pablo Basanta-Val, Marisol García-Valls,
and Iria Estévez-Ayres
mailto:pbasanta@it.uc3m.es
†Jornadas de Tiempo Real 2011- Madrid( )
Publicado en ACM Transactions On Embedded Systems
2. Outline
• Context and Motivation
• No-Heap Remote Objects
– Basic Model
• Programming model
• Example
• Performance
– Extended Model
• Programming patterns
• Extended model
• Performance
• Conclusion and ongoing work
2
3. Memory management for real-
time Java
• Techniques used for memory management in real-time Java
(RTSJ)
– Auto-managed memory (object pools)
– Garbage collection (and its RT* variants)
– Regions (ScopedMemory)
• Memory management issues in distributed real-time Java
(DRTSJ)
– Real-time garbage collection
– Distributed Garbage Collection
– Regions
• Current garbage collectors may be not enough for
distributed real-time applications
– E.g. a heap with 1Gb may introduce a 30 seconds delay
JRT-11 3
4. State of the art
Denomination Technologies Goals
RT- CORBA+ Implementation of RT-CORBA with RTSJ
RTZen
RTSJ
DRTSJ RMI+RTSJ A specification for distributed real-time Java
RT-RMI-York RMI+RTSJ A framework for distributed real-time Java.
RT-RMI-UPM RMI+RTSJ Profiles for distributed real-time Java
DRTJava-on-CSP CSP+Java Produce an alternative based on CSP formalisms
RTJ-COM RTSJ A component framework for embedded Java
Scratchpad RTSJ A no-heap component model for real-time Java
A distributed real-time object-oriented platform
APICOM RTSJ +CAN
• There is not a simple technique to remove the GC’s from the
server side !!!
• RTZen hybrid approach,
• DRTSJ , RTRMI-York, RTRMI-UPM take non-heap as a requirement
JRT-11 4
5. RTSJ region-based memory model
• Three types of memory areas :O1=new Object
– Heap
– Immortal Memory (I)
– Scoped Memory (Sx)
O1
• A selector mechanism Sa
1
– One scope stack per thread
– Enter, executeInArea Sb
O2
1
• Destruction mechanism I
– Stack discipline (counter)
• Safety mechanism Scope Stack
– Assignment rule
– Single parent rule Forbidden assignment
Default allocation
5
context
6. Calculator() Calculator()
NhRo: memory model
lastInteger lastInteger
add() add()
lastResult() lastResult()
doNothing() doNothing()
• Fragmented memory model
– Creation Context
• Represents the state of the remote object
– Invocation Context
• Objects created during remote invocation
• Safe nesting of contexts
– NhRo-rule: references from creation to invocation are
forbidden
– References from invocation to creation are allowed
6
8. NhRo: Impact on the middleware
Scoped or Immortal
CalculatorImpl_Stub CalculatorImpl
lastInteger
add() add()
lastResult() lastResult()
doNothing() doNothing() Programmer
Layer
ObjId Ref CC
Invocation max
Invocation 1
CalcID
Immortal memory
0
0
Remote Object Table Thread Memory Area
Pool Pool Middleware
Layer
JRMP/IIOP
Transport Transport
RTSJ
Virtual
Machine
Client Server
8
9. NhRo in action
Calculator() Creation Context
lastInteger
(Immortal Memory)
add()
lastResult() Invoc. Context
doNothing()
(LTMemory)
CalcID Ref
OBJId Table
enter
0 0 1
0
Thread Memory Area objID a b
pool pool
meth tmp ser
1
Transport
CalcID.add(DataInt(3),DataInt(4)) Middleware
Program
DataInt(7) created created
object object 9
10. NhRo vs. traditional
GC’d remote objects
Garbage collector RTSJ-RI Memory area pool Garbage collector RTSJ-RI Memory area pool
8
16
7
14
6
Consummed time (ms)
12
Consummed time (ms)
5
10
4
8
3
6
2 4
1 2
0 0
1 21 41 61 81 101 121 141
752
1286
1910
2534
3158
sample
Alive memory (kB)
JRT-11 10
11. Enhancements to the basic NhRo
model
• Patterns for programming with NhRos
• NhRo stored in scoped memory
– Scope stack characterization
– Changes in the middleware
– Policies for the memory are pool
• Performance issues
– Dependency on data transmitted
JRT-11 11
12. Calculator()
NhRo: constraints (I)
lastInteger
add()
lastResult()
doNothing()
• NhRo-rule limitations
– Objects is creation context are destroyed after
remote invocation by default
• Two patterns to avoid the problem
– Copy pattern
– Extended portals
12
13. NhRo: Scope Stack at the server
Invocation
context
:RO1=new RemoteObject Sinv1 a b
Handler 1
Thread
Sa RO1 Sa RO1
Creation context
Creation context
1 1
Sb Sb 1
1
I I
Scope Stack Scope Stack
(during remote object creation) (during remote invocation)
• Creation context: state of the remote object
• Invocation context: parameters of remote invocation 13
15. Invocationnumber
Memory Area Pool
Invocationsize
0 0 0
Memory Area
• It stores LTMemory instances only Pool
• It requires two configuration parameters
– Number of instances in the pool
– Memory associated to each invocation context
• Auto-collection
– Invocation context returns automatically to its pool when
they are not used
• Internal counter 1→0
• Avoids memory area leakage
15
16. bytes
5000
0
10000
15000
20000
25000
30000
void
boolean
byte
char
short
int
long
float
double
null
Byte
Short
Integer
Long
Float
Double
Character
X
Boolean
RtUnRemOb
String()
JRT-11
String(10)
and LTMemory size
String(25)
String(50)
String(100)
Object[0]
Object[10D]
Object[25D]
Object[50D]
Object[100D]
Vector(0)
Vector(10D)
Vector(25D)
Vector(50D)
Vector(100D)
Remove invocation parameters
X echo(X)
X doNothing()
void doNothing(X)
16
18. Conclusions
• This work has introduced a model able to remove
the garbage collection from the end-to-end path
– NhRo model
• Empirical results showed:
– Its implementation in basic environments is simple
– The performance patterns offered are powerful
JRT-11 18
19. Ongoing Work-
• To produce an analytic model for the NhRo
– Use of heap, and different threads
– Identification of useful combinations
• Analyze the parentage-rules proposed by Higuera-
Toledano and integrate them with NhRos
– A more restricted model
JRT-11 19
From the programmer perspective, the memory model of the region based remote objects, the memory is fragmented is fragmented in two contexts. The first of this contexts is the creation context The creation context contains all objects that are accessible from the remote object instance; that is, all objects that are accessible from the state of the attibutes. The second of the contexts is the invocation context. The invocation context contains all objects that are created as consequence of the remote invocation. All objects created in the remote methods of the object belongs to the invocation context. Besides there is a safety rule. This rule is kown as NhRo-rule. It states that the objects created during the remote invocation may not be references from those that belonging the creaation context. The opposite is posible, an object stored in creation context may be referenced from the creation context.