On Aug. 8th 2010, presented in reading session #5 for GC book.

1. GC in C++0x
Aug. 8th 2010 / Reading session for GC book
Yasutaka ATARASHI
@yak_ex

2. Self introduction
 Name: Yasutaka ATARASHI
 Twitter ID: yak_ex
 Web: http://yak3.myhome.cx:8080/junks
(written in Japanese)
 Main languages: C++ / Perl
 Currently, not coding in office
 Coding in programming competitions
(TopCoder and Codeforces)
 Not familiar with GC
 Therefore, this slide may include errors :p

3. GC is widely spread
 Languages in Google Code Jam 2010 Qualifier
1st C++ 4911 6th Ruby 221
2nd Java 2762 7th PHP 170
3rd Python 1459 8th Perl 146
4th C 751 9th Haskell 118
5th C# 648 10th Pascal 95

4. GC is widely spread
 Languages in Google Code Jam 2010 Qualifier
1st C++ 4911 6th Ruby 221
2nd Java 2762 7th PHP 170
3rd Python 1459 8th Perl 146
4th C 751 9th Haskell 118
5th C# 648 10th Pascal 95
 Yellow means languages with GC

5. GC is widely spread
 Languages in Google Code Jam 2010 Qualifier
1st C++ 4911 6th Ruby 221
2nd Java 2762 7th PHP 170
3rd Python 1459 8th Perl 146
4th C 751 9th Haskell 118
5th C# 648 10th Pascal 95
 Yellow means languages with GC
 C++ is outlier: Widely used but without GC

6. GC is widely spread
 Languages in Google Code Jam 2010 Qualifier
1st C++ 4911 6th Ruby 221
2nd Java 2762 7th PHP 170
3rd Python 1459 8th Perl 146
4th C 751 9th Haskell 118
5th C# 648 10th Pascal 95
 Yellow means languages with GC
 C++ is outlier: Widely used but without GC
 However, C++ is the extreme multi-paradigm language.
Finally, it has …

7. C++: The extreme multi-paradigm
language
 The next standard, aka C++0x, has
Support for
Garbage Collection
and
Reachability-Based Leak Detection

8. C++: The extreme multi-paradigm
language
 The next standard, aka C++0x, has
Minimal Support for
Garbage Collection
and
Reachability-Based Leak Detection

9. Minimal Support for GC (snip)
 Some concepts
 Traceable pointer object
 Safely-derived pointer (value)
 5 functions
 get_pointer_safety()
 (un)declare_no_pointers()
 (un)declare_reachable()

10. Some concepts (1)
 Traceable pointer object
 Pointer object, or
 Integer object whose size is enough to hold
pointer, or
 A sequence of elements in an array of character
type
(Probably, strict aliasing rule restricts that they
type is character type only)
-> Object that implementation can recognize that it
may have pointer value
= Assuming the other area don’t have pointer value

11. Some concepts (2)
 Safely-derived pointer (value)
 The value returned by ::operator new (e.g. new T), or
 Operations on safely-derived pointer value, or
 Address taken on dereference (e.g. &*p)
 Well-defined pointer arithmetic (e.g. p+1)
 Well-defined pointer conversion
(e.g. static_cast<void*>(p))
 reinterpret_cast between pointer and integer
(e.g. reinterpret_cast<intptr_t>(p))
-> Pointer value that implementation can trace that
 the area designated by the pointer is allocated
by ::operator new and
 the pointer value is valid

12. Some concepts (3)
 Safely-derived pointer (value)
This is safely-derived pointer value
T *p = new T;
intptr_t x = reinterpret_cast<intptr_t>(p) ^ 0x555
a:
T *q = reinterpret_cast<T*>(x ^ 0x555);
T y = *q;
This is not safely-derived pointer value
This is NOT safely-derived pointer value, either!
The value is the same as p but determined
not by value but by process

13. Minimal Support for GC (snip)
 Some concepts
 Traceable pointer object
 Safely-derived pointer (value)
 5 functions
 get_pointer_safety()
 (un)declare_no_pointers()
 (un)declare_reachable()

14. Function: get_pointer_safety()
 Returns pointer-safety of the
implementation
Behavior does not depend on whether the
 relaxed: value is safely-derived pointer, like as C++03
• relaxed and preferred are implementation-
 preferred: defined
• In the case of “preferred”, there may be
leak detector
• In VC2010, relaxed is always returned
and the other functions has no-effect.
 strict: Undefined behavior when dereferencing
or deallocating via not safely-derived pointer
value which declare_reachable(), as
described later, is not called for.

15. Strict pointer safety
 Safely-derived pointer (value)
This is safely-derived pointer value
T *p = new T;
intptr_t x = reinterpret_cast<intptr_t>(p) ^ 0x555
a:
T *q = reinterpret_cast<T*>(x ^ 0x555);
T y = *q;
This is not safely-derived pointer value
This is NOT safely-derived pointer value, either!
Undefined
The value is the same as p but determined
behavior
not by value but by process

16. Function:
(un)declare_no_pointers()
 void declare_no_pointers(char *p,
size_t n);
 void undeclare_no_pointers(char *p,
size_t n);
 Declares or undeclares that the
specified area does not have pointer
value
-> Enable to restrict scan area by GC

17. Function: (un)declare_reachable
 void declare_reachable(void *p);
 Declare that object designated by safely-
derived pointer value p is reachable
-> Excludes the object from target of GC
 template<class T>
T* undeclare_reachable(T *p);
 Returns safely-derived pointer value which is the
same value as p. The object designated by p
must be reachable.
-> The object becomes target of GC again
(NOTE: The return value is safely-derived so that
the object is not GC-ed while the value is alive)

18. Usage of (un)declare_reachable()
 Why needed? This is safely-derived pointer value
T *p = new T;
intptr_t x = reinterpret_cast<intptr_t>(p) ^ 0x555
a:
T *q = reinterpret_cast<T*>(x ^ 0x555);
T y = *q;
This is not safely-derived pointer value
This is NOT safely-derived pointer value, either!
Undefined
The value is the same as p but determined
behavior
not by value but by process
A GC at label a might reclaim the object designated by p ???

19. Usage of (un)declare_reachable()
 Why needed? This is safely-derived pointer value
T *p = new T;
intptr_t x = reinterpret_cast<intptr_t>(p) ^ 0x555
a:
T *q = reinterpret_cast<T*>(x ^ 0x555);
T y = *q;
This is not safely-derived pointer value
This is NOT safely-derived pointer value, either!
Undefined
The value is the same as p but determined
behavior
not by value but by process
A GC at label a might reclaim the object designated by p Optimization
issue

20. Usage of (un)declare_reachable()
 Why needed?
T *p = new T; p is not used
intptr_t x = reinterpret_cast<intptr_t>(p) ^ 0x555 afterwards
a:
T *q = reinterpret_cast<T*>(x ^ 0x555);
T y = *q;
NOTE: p, x, q can be assigned to the same register x is not used
-> the value p does not exist anywhere at the label a afterwards
-> the object designated by p (and q) can be collected
by GC!!
-> *q causes undefined behavior
A GC at label a might reclaim the object designated by p Optimization
issue

21. Usage of (un)declare_reachable()
 Correct code in C++0x
*p is
reachable T *p = new T;
= declare_reachable(p); // Call before disguising
Ignored intptr_t x = reinterpret_cast<intptr_t>(p) ^ 0x555
by GC a:
// T z = *reinterpret_cast<T*>(x ^ 0x555); // Legal
// Call undeclare_reachable() after disguising
T *q = undeclare_reachable(reinterpret_cast<T*>(x ^ 0x555));
T y = *q;
NOTE
- The same value called for declare_reachable is dereferencable even though it is not safely-derived.
- Argument of undeclare_reachable is not needed to be safely-derived, and must be reachable.
- Regarding declare_reachable, the problem is disguising pointer
Considering functions separated at the a:, the same discussion is applicable w/o optimization.

22. Summary
 C++0x has minimal support for GC
 Concept: Safely-derived pointer
= Valid pointer value which is target of GC
 5 new functions
 C++03 behavior is conformant in relaxed
safety
 Unlikely to release strict-safety implementation
immediately
 Code disguising pointer value needs
modification by using
declare_reachable() / undeclare_reachable()

23. Reference
 N2670: Minimal Support for Garbage
Collection and Reachability-Based Leak
Detection (revised)
http://www.open-
std.org/jtc1/sc22/wg21/docs/papers/2008/
n2670.htm
 Garbage Collection in the Next C++
Standard
http://www.hpl.hp.com/techreports/2009/H
PL-2009-360.pdf