GC Assertions: Using the Garbage Collector To Check Heap Properties Samuel Z. Guyer Tufts University Edward Aftandilian Tufts University

2 PLDI, June 16-18, 2009 Motivation Real-world programs are complex Programmer may not understand whole application Global knowledge required to understand seemingly local properties Mismatch between programmer’s expectation and actual behavior causes bugs

3 PLDI, June 16-18, 2009 I think I understand my program Example from SPEC JBB2000 Clients in a district enter orders Warehouses fullfill orders from their district When district is torn down, orders are deleted order appears to become unreachable here Enumeration orderIter = orderTable.elements(); Order order; while (orderIter.hasMoreElements()) { order = (Order)orderIter.nextElement(); orderTable.removeEntry(order.getId()); Factory.deleteEntity(order); } Factory.deleteEntity(orderTable); orderTable = null;

4 PLDI, June 16-18, 2009 I don’t understand my program Wrong! Customer object maintains reference to order Memory leak order customerorderTable

5 PLDI, June 16-18, 2009 Existing solutions Inspect the code Static analysis False positives Run-time invariant checking Slow: x overhead[Shankar 07] Heuristics (staleness, anomaly detection) False positives

6 PLDI, June 16-18, 2009 Our solution: GC assertions Programmer adds assertions to code Express expected program properties Piggyback on garbage collector to check expected properties More precise than static analysis More efficient then run-time invariant checking Less than 3% overhead More accurate than heuristics

7 PLDI, June 16-18, 2009 How GC assertions work Insert assertions into program code Assertions executed during program run Store metadata about each assertion Assertions batched and checked at next GC Multiple assertions can be checked in a single heap traversal – fast! Only checked at GC time We may miss transient errors Trade completeness for performance

8 PLDI, June 16-18, 2009 Implementation Jikes RVM Goal: fast during correct program execution Implemented in a pure mark-sweep collector Generational collector would perform better but have longer time-to-detection Basic strategies: Steal bits from object header, check during GC tracing Change order of heap traversal

9 PLDI, June 16-18, 2009 Kinds of properties we can check Lifetime properties Volume properties Shape properties

10 PLDI, June 16-18, 2009 Lifetime properties Problem: Object that appears to be unreachable may not actually be reclaimed No direct way to find out if a specific object is reclaimed Difficult to determine through program inspection Solution: assert-dead(p) *p should be reclaimed at next collection

11 PLDI, June 16-18, 2009 Lifetime properties Problem: Server app – all objects allocated while servicing a connection should die when the connection terminates How do we find out which objects were allocated for that connection? Solution: start-region(); … service connection … assert-alldead(); Any object allocated between these two calls should be reclaimed at the next collection

12 PLDI, June 16-18, 2009 Volume properties Problem: Only one instance of a class should be live at any time (singleton pattern) Multiple class loaders, subclassing, serialization, etc. make this difficult to enforce [Sun Developer Network] Solution: assert-instances(T, I) Number of live objects of type T should not exceed I

13 PLDI, June 16-18, 2009 Implementation assert-dead, assert-unshared Steal bit from object header, look for set bit during GC tracing assert-alldead Maintain a per-thread list of objects allocated inside a region. When region ends, mark all objects in list as dead. assert-instances RVMClass object tracks instance limit and instance count. Count updated during GC.

14 PLDI, June 16-18, 2009 Shape properties Problem: Nodes in a tree should never have more than one incoming pointer Solution: assert-unshared(p) At most one object points to *p

15 PLDI, June 16-18, 2009 Shape properties Problem: Objects in a collection are pointed to by a separate index. Index should never point to an object that is no longer in the collection. Index should not keep object alive Solution: assert-ownedby(p, q) Some path from root to p passes through q

16 PLDI, June 16-18, 2009 Implementing assert-ownedby Error! Main container Hash table

17 PLDI, June 16-18, 2009 Implementation assert-ownedby Phase 1: Perform a heap scan starting at each owner Don’t mark the owner yet – we don’t know if it is reachable If we encounter an ownee, check to make sure it belongs to the current owner. If not, error. If we encounter another owner, mark it and stop the scan Phase 2: Perform the normal heap scan starting at the roots If we encounter any ownee that is not marked, error

18 PLDI, June 16-18, 2009 Finding the error When assertion is triggered, how to find bug? Most assertions related to reachability and paths through the heap Provide full path through heap to object Sequence of references/objects from root to offending object Helps determine which data structure is keeping an object alive Small change to the object tracing code

19 PLDI, June 16-18, 2009 Example full-path output Warning: an object that was asserted dead is reachable. Type: Lspec/jbb/Order; Path to object: Lspec/jbb/Company; -> Lspec/jbb/infra/Collections/StringStaticBTree; -> Lspec/jbb/infra/Collections/StringBTreeNode; -> [Ljava/lang/Object; -> Lspec/jbb/infra/Collections/StringBTreeNode; -> [Ljava/lang/Object; -> Lspec/jbb/infra/Collections/StringBTreeNode; -> [Ljava/lang/Object; -> Lspec/jbb/Customer; -> Lspec/jbb/Order;

20 PLDI, June 16-18, 2009 Performance Benchmarks: SPEC JVM98, SPEC JBB 2000, DaCapo Three configurations: Base – unmodified RVM, unmodified benchmarks Infrastructure – modified RVM, unmodified benchmarks WithAssertions – modified RVM, modified benchmarks 16k assertions in db, 15k checked at each GC 31k assertions in jbb, 400 checked at each GC

21 PLDI, June 16-18, 2009 Run-time overhead Geomean: 2.75% slowdown for Infrastructure

22 PLDI, June 16-18, 2009 GC time overhead Geomean: 13.4% slowdown for Infrastructure

23 PLDI, June 16-18, 2009 Run-time overhead Geomean: 1.0% slowdown for WithAssertions

24 PLDI, June 16-18, 2009 GC time overhead Geomean: 19.9% slowdown for WithAssertions

25 PLDI, June 16-18, 2009 Finding bugs SPEC JBB 2000 Uses Factory pattern with destroy() methods Instrument destroy() methods with assert- dead() assertions Also instrument loops where it is clear an object should be unreachable at the end of the loop

26 PLDI, June 16-18, 2009 Finding bugs Found several bugs: “Dead” Order objects reachable from Customer objects; same with Address objects In main program loop, a reference is kept to the Company object from the previous iteration Order objects not properly removed from an orderTable when a DeliveryTransaction is completed Full-path information was very helpful Order bugs could be found more easily with assert-ownedby

27 PLDI, June 16-18, 2009 Conclusion GC is a powerful source of information about program state Can check properties, such as lifetime, that no other subsystem has access to By piggybacking on the existing GC tracing algorithm, we can check interesting properties at low cost Knee in curve of cost/precision tradeoff

28 PLDI, June 16-18, 2009 Thank you! Questions?