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