This document proposes strategies for implementing a distributed garbage collection service for distributed real-time Java applications. It discusses turning off the default garbage collector or implementing a predictable real-time version. A real-time garbage collector would make reference and unreference methods prioritized tasks and lease renewals periodic tasks. An evaluation shows that a real-time garbage collector can avoid priority inversions and that deferred cleanup reduces response times compared to the default synchronous approach. The work aims to reduce garbage collection overhead for distributed real-time Java applications.

1. 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
2

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
3

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
4

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)
5

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
6

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;
}
7

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
8

9. Memory Leaks
avoided 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)
9

10. Memory Leaks
avoided 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
10

11. Relationship between the registry and the
DGC service
 The registry holds references to remote objects !!!
11

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
12

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
13

14. Strategies for a real-time DGC service
 Two 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)
14

15. Strategies for a real-time DGC service
Turning DGC off
 Remote objects may removed at the server (with
current API).
00:UnicastRemoteObject
01: static boolean
02: unexportObject
03: (Remote r, bolean force)
04: throws NoSuchObjectException;
 But it could be extended with a method to list all
objects
00: UnicastRealtimeRemoteObject
01: static Vector
02: listExportedRemoteObjects();
Server node
15

16. Strategies for a real-time DGC service
Turning DGC off (2)
 To allow explicit deallocation from a client
00: RealtimeRemote
01: boolean unReference(Remote r)
02: throw NoSuchObjectException;
16

17. Strategies for a real-time DGC service
Turning DGC off
 Remote objects may removed at the server (with
current API).
00:UnicastRemoteObject
01: static boolean
02: unexportObject
03: (Remote r, bolean force)
04: throws NoSuchObjectException;
 But it could be extended with a method to list all
objects
00: UnicastRealtimeRemoteObject
01: static Vector
02: listExportedRemoteObjects();
Server node
17

18. Strategies for a real-time DGC service
real-time DGC
 Based on the redefinition of:
 Reference method
 Unreference method
 Leasing mechanism
18

19. Strategies for a real-time DGC service
real-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
19

20. Strategies for a real-time DGC service
real-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
20

21. Strategies for a real-time DGC service
real-time DGC- lease
 Lease
 Invoked periodically
 Modeled as periodic real-time invocation (T,D,C, Priority)
21

22. Strategies for a real-time DGC service
real-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
22

23. Performance evaluation
goals
 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)
23

24. Performance evaluation
priority inversion trends
 A scenario that shows
unbounded priority
inversion was build
 Thread in client suffers
priority inversion of al
24

25. Performance evaluation
priority inversion due to DGC
 The real-time garbage collector may handle the priority
properly
100
400
1600
6400
25600
100
1300
2500
3700
4900
6100
7300
8500
9700
10900
12100
WCRT(µs)
T3_WCET (µs)
RT-DGC and DGC impact on Worst Case Response Times
CLIENT (with DGC)
CLIENT (with RT-DGC)
T3 (with DGC & RT-DGC )
25

26. Performance evaluation
deferred vs. synchronous costs
 Defered DGC reduces response times
26

27. Performance evaluation
leasing trends
 Above 1 minute the cost reduces remarkably (RMI default is 5 mins)
27

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
28

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
29

30. Thank you (谢谢)
30