Towards Distributed Garbage Collection for Distributed Real-Time Java
Pablo Basanta Val and Marisol García Valls Universidad Carlos III de Madrid (SPAIN) www.it.uc3m.es/drequiem/
2
Outline (概述 ) Context & Approach
Real-time Java status Motivations for having a DGC service
Strategies for a RT-DGC service Turning-off the DGC service Defining a simple RT-DGC service
Evaluation Priority inversion illustration Blocking time introduced in remote communications Leasing overhead
Conclusions and future work
3
Context Next generation real-time systems
More dynamic & complex
One approach to address this issue is to use high-level development languages like real-time Java Provide developers with libraries and potentially may reduce the development
cost of applications
However, Java was not initially designed for real-time systems Many features (e.g. garbage collectors collide with real-time performance) Research efforts are required to harmonize real-time performance with Java
4
State of the Art in Real-time Java Centralized systems
Java VM, Specifications (RTSJ), Running products (Oracle, IBM, Jamaica) Currently in refinement in JSR-282
Safety critical applications Ongoing specifications and implementations Active in JSR-302
Distributed real-time Java Ongoing specifications (DRTSJ), and partial implementations (based on Java’s RMI) Stalled in JSR-50 and relaunched in 2012
5
This work contribution Improves garbage collection mechanisms included in Java’s RMI with real-
time performance Characterization of messages Initial performance indicators and clues Evaluation of different alternatives
Benefits for the real-time Java community Useful for DRTSJ and other real-time RMI implementations
Currently they do not provide operative approaches Backward compatible with RTSJ (no changes required)
6
Distribution real-time Java model
Based on the DREQUIEMI’s framework for distributed real-time Java It runs directly on RTSJ It extends Java’s RMI (Remote Method Invocations)
with predictability It offers a predictable garbage collector for RMI
Predictable =
configurable priorities + scheduling parameterization
7
API of the scheduling service (in DREQUIEI)
package es.uc3m.it.drequiem.rtrmi.server.dgc;
import java.rmi.server.dgc.*;
public interface RTDGCInterface extends java.rmi.Remote{
public void referenced(java.rmi.server.ObjID objid)
throws java.rmi.RemoteException;
public void unreferenced(java.rmi.server.ObjID objid)
throws java.rmi.RemoteException;
}
8
Motivation for having a distributed garbage collector Java requires a garbage collector
50% of all Java methods may allocate objects Static allocation is not a practical solution
A distributed garbage collector is not mandatory in real-time Java It is not no so necessary as a local garbage collector (remote objects may be
removed manually like in CORBA) However, it may be beneficial in terms of collecting unused remote objects
RMI uses the model To remove unwanted remote objects
9
Memory Leaksavoided in Sun DGC DGC in RMI is based on
counting algorithms It is not able to remove
remote object cycles (to avoid problems)
Acyclic structures may be collected (like the one in the figure)
10Memory Leaksavoided in Sun DGC(2) Each potential invoation
to remoteObjectLeak creates a memory leak After n invocations, there
are n remote objects that may be collected
11
Relationship between the registry and the DGC service
The registry holds references to remote objects !!!
12
Sun’s DGC algorithm sketched-reference list Based in leasing and
reference lists Based on a algorithm
described by Birrell previously
Reference lists prevent remote object deallocation
Remote references avoid remote object destruction
13
Sun’s DGC algorithm sketched-Leasing Leasing
To deal with faulty scenarios
Basic idea to wait for an update periodically
Periodical renewal associated to a remote reference
14
Strategies for a real-time DGC serviceTwo approaches
To turn off DGC it requires new API methods to remove remote objects
To produce a predictable version of DGC Requires a clear definition of priorities, periods
(So that it may be schedulable as a real-time task)
15
Strategies for a real-time DGC serviceTurning DGC off
Remote objects may removed at the server (with current API).
00:UnicastRemoteObject01: static boolean 02: unexportObject03: (Remote r, bolean force)04: throws NoSuchObjectException;
But it could be extended with a method to list all objects
00: UnicastRealtimeRemoteObject01: static Vector 02: listExportedRemoteObjects();
Server node
16
Strategies for a real-time DGC serviceTurning DGC off (2)
To allow explicit deallocation from a client
00: RealtimeRemote01: boolean unReference(Remote r)02: throw NoSuchObjectException;
17
Strategies for a real-time DGC serviceTurning DGC off
Remote objects may removed at the server (with current API).
00:UnicastRemoteObject01: static boolean 02: unexportObject03: (Remote r, bolean force)04: throws NoSuchObjectException;
But it could be extended with a method to list all objects
00: UnicastRealtimeRemoteObject01: static Vector 02: listExportedRemoteObjects();
Server node
18
Strategies for a real-time DGC servicereal-time DGC
Based on the redefinition of: Reference method Unreference method Leasing mechanism
19
Strategies for a real-time DGC servicereal-time DGC- reference
Reference Invoked each time a remote reference abandons a node The priority of the transaction is the priority of the thread that carries out that action
20
Strategies for a real-time DGC servicereal-time DGC- unreference Reference
Invoked each time a remote reference is invoked
The priority of the transaction is the priority of the thread that carries out that action
21
Strategies for a real-time DGC servicereal-time DGC- lease
Lease Invoked periodically Modeled as periodic real-time invocation (T,D,C, Priority)
22
Strategies for a real-time DGC servicereal-time DGC- decoupled mechanisms
To avoid synchronous reference and unreference methods Able decouple cost from
remote invocations The reference and
unreference methods are modelled as T,D,C transactions
23
Performance evaluationgoals To build an scenario that illustrates that illustrates
performance trends of current
To evaluate the overhead introduced by the synchronous/asynchronous remote invocations
To evaluate the overhead introduced by the leasing mechanism
Reference software 796 Mhz machines x 1 real-time router (100 Mbits second)
24
Performance evaluationpriority inversion trends
A scenario that shows unbounded priority inversion was build Thread in client suffers
priority inversion of al
25
Performance evaluationpriority inversion due to DGC
The real-time garbage collector may handle the priority properly
26
Performance evaluationdeferred vs. synchronous costs
Defered DGC reduces response times
27
Performance evaluationleasing trends
Above 1 minute the cost reduces remarkably (RMI default is 5 mins)
28
Conclusions (结论 ) Distributed real-time Java applications require to deal with the garbage
collector issue (disabling the DGC) Illustrated empirically
The paper provides mechanisms to reduce the cost of garbage collection in distributed real-time Java Illustrated empirically
29
Ongoing work Extensive evaluation and formalization
Benchmarks and formalism for the real-time DGC
An extension to other real-time infrastructures Used to collect real-time SOA
30
Thank you (谢谢 )