Towards Distributed Garbage Collection for Distributed Real-Time Java

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

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 theschedulingservice(in DREQUIEI) packagees.uc3m.it.drequiem.rtrmi.server.dgc; import java.rmi.server.dgc.*; public interface RTDGCInterfaceextends java.rmi.Remote{ public void referenced(java.rmi.server.ObjIDobjid) throws java.rmi.RemoteException; public void unreferenced(java.rmi.server.ObjIDobjid) throwsjava.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)

10. Memory 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 Remotereferencesavoidremoteobjectdestruction

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

15. Strategies for a real-time DGC serviceTurning DGC off • Remote objects may removed at the server (with current API). 00:UnicastRemoteObject01: static boolean02: 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: booleanunReference(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 boolean02: 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 fromremote 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 (谢谢)