Presentation is loading. Please wait.

Presentation is loading. Please wait.

Garbage Collection in the Next C++ Standard Hans-J. Boehm, Mike Spertus, Symantec.

Similar presentations

Presentation on theme: "Garbage Collection in the Next C++ Standard Hans-J. Boehm, Mike Spertus, Symantec."— Presentation transcript:

1 Garbage Collection in the Next C++ Standard Hans-J. Boehm, Mike Spertus, Symantec

2 The Context (1) Conservative garbage collection for C and C++ has been used for 20+ years. –Usually works, possibly with a small amount of tweaking. –Especially for 64-bit applications. More attractive with multi-core processors. –Explicit memory management gets harder with threads. –Some parallel programming techniques much more difficult/expensive without GC. –GC parallelizes better than malloc/free. GC-based leak detectors are also common. One major limiting factor: –C and C++ standards dont fully sanction garbage collecting implementations. –Programmers are hesitant to use nonstandard tools.

3 The Context (2) C++ standard is undergoing revision. C++0x expected somewhere near 2010 or 2011. –Initial committee draft was put out for review. Many other new features: –Concepts (Templates type-checked in isolation). –Threads support (threads API, memory model, atomics). struggling with object lifetime issues. –Library-based classic reference counting ( shared_ptr ). –R-value references (references to otherwise inaccessible values) support low-cost shared_ptr moves. Microsofts C++/CLI provides a separate garbage- collected heap.

4 Our Goal Transparent garbage collection. –Ordinary pointers; works with existing library code. –Supports Code designed for GC Leak detection Litter collection –Supports atomic pointers with cheap assignment.

5 Our Proposal, version 1 GC support in the implementation mandatory. GC use optional, but must be consistent across application. –If you have to trace a section of the heap, you might as well collect it. Program sections specify gc_forbidden, gc_required, or gc_safe (default). –Linker diagnoses conflicts. Annotations can specify when integral types may contain pointers. This proposal is currently on hold, not in CD.

6 Issues with original proposal (1) gc_required / gc_forbidden must be consistent for whole program: –Too coarse. –Need to deal with plug-ins with limited interface.

7 Issues with original proposal (2) Finalization is needed for interaction of GC with explicit resource management. Finalization is problematic in the presence of dead variable elimination. class C { int indx; // E[indx] contains // associated data. // Finalizer cleans up E[indx] void foo() { int i = indx; // this dead here. // May be finalized? bar(E[i]); }

8 Our proposal, version 2 Minimal compromise proposal –Garbage collected implementations are allowed, not required. Officially allows collection of memory allocated with built-in operator new. –malloc() is arguably in the domain of the C committee. –malloc() garbage collection may be harder to retrofit. Not intended as long term replacement for proposal 1. In current Committee Draft.

9 Proposal 2 components 1.Allow unreachable objects to be reclaimed. 2.Provide a simple API to Explicitly prevent reclamation of specified objects ( declare_reachable() ). Declare that certain objects do not need to be traced because they contain no pointers ( declare_no_pointers() ).

10 Reclamation of unreachable objects in C++ Existing conservative collectors reclaim objects not reachable via pointer chains from variables. Leak detectors make similar assumptions. intptr_t q = ~(intptr_t)p; p = 0; … p = (foo *)(~q); … *p … But current standard does not guarantee that unreachable objects are dead. Disallow this! Unavoidably a compatibility issue

11 This isnt as easy as it looks … Initial attempt: –Objects that were once unreachable may not be dereferenced (incl. deallocation). Insufficient: int_ptr_t q = ~(intptr_t)p; … foo *r = (foo *)(~q); p = 0; … *r …

12 A better formulation Only safely-derived pointers may be dereferenced. A safely-derived pointer was computed without intervening integer arithmetic from another safely- derived pointer. Safely-derived pointers may only be stored in –pointer objects. –integer objects of sufficient size. –aligned character arrays. Whether a value is safely derived depends on how it was computed, not on the bits representing the pointer. –Sometimes p safely derived, r not, but p == r. Draft standard contains a precise inductive definition. Thanks to Clark Nelson (Intel).

13 API addition 1 Declare_reachable() / undeclare_reachable() allow a pointer to be dereferenced even if it is not safely-derived. –No-ops in non-GC implementation. –Allow old code to be retrofitted. Undeclare_reachable() returns safely derived copy of pointer.

14 Declare_reachable() example declare_reachable(p); int_ptr_t q = ~(intptr_t)p; p = 0; … p = undeclare_reachable(foo *)(~q); … *p …

15 Implementation Challenges Implemented as global GC-visible multiset representation, but: –Declare_reachable() applies to complete objects. Undeclare_reachable() argument need not match exactly. –Matching calls dont need to come from the same thread: Scalability with thread/processor count.

16 API Addition 2 Declare_no_pointers(p,n) / undeclare_no_pointers(p,n) declares the address range [p, p+n) to not hold pointers; safely derived pointers may not be stored there. Allows the programmer to specify more type information. Much more compatible with C++ constructor/destructor model than allocation-time specifications. Can be applied to static/stack/heap objects. Undeclare_no_pointers() must be called before explicit deallocation.

17 Declare_no_pointers () example class foo { foo * next; char cmprsd[N]; public: foo() { … declare_no_pointers(cmprsd, N); } ~foo() { … undeclare_no_pointers(cmprsd, N); } … }

18 Implementation Challenges Efficient handling for frequently constructed stack objects. Scalability.

19 Prototype Implementation Currently just track registered ranges. –Processing deferred to GC time. Keep a small number of ranges in a thread-local data structure. Very small ranges and smaller objects are currently ignored.

20 Preliminary Performance Measurements processor nsecs/op-pair threads

21 Conclusions Current C++0x draft explicitly allows garbage-collected implementations. Support APIs differ from existing implementations. –For good reasons, we think. New set of implementation challenges. More extensive GC support will be considered after C++0x. Not too late for comments.

22 Questions?

Download ppt "Garbage Collection in the Next C++ Standard Hans-J. Boehm, Mike Spertus, Symantec."

Similar presentations

Ads by Google