GC in C++0x [eng]

1,509 views

Published on

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

Published in: Technology
0 Comments
0 Likes
Statistics
Notes
  • Be the first to comment

  • Be the first to like this

No Downloads
Views
Total views
1,509
On SlideShare
0
From Embeds
0
Number of Embeds
3
Actions
Shares
0
Downloads
6
Comments
0
Likes
0
Embeds 0
No embeds

No notes for slide

GC in C++0x [eng]

  1. 1. GC in C++0x Aug. 8th 2010 / Reading session for GC book Yasutaka ATARASHI @yak_ex
  2. 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. 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. 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. 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. 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. 7. C++: The extreme multi-paradigmlanguage The next standard, aka C++0x, has Support for Garbage Collection andReachability-Based Leak Detection
  8. 8. C++: The extreme multi-paradigmlanguage The next standard, aka C++0x, has Minimal Support for Garbage Collection andReachability-Based Leak Detection
  9. 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. 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. 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. 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. 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. 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. 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. 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. 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. 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 processA GC at label a might reclaim the object designated by p ???
  19. 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 processA GC at label a might reclaim the object designated by p Optimization issue
  20. 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 behaviorA GC at label a might reclaim the object designated by p Optimization issue
  21. 21. Usage of (un)declare_reachable()  Correct code in C++0x*p isreachable T *p = new T;= declare_reachable(p); // Call before disguisingIgnored intptr_t x = reinterpret_cast<intptr_t>(p) ^ 0x555by 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. 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. 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

×