GC in C++0x

Aug. 8th 2010 / Reading session for GC book

Yasutaka ATARASHI

@yak_ex

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

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

GC is widely spread

Languages in Google Code Jam 2010 Qualifier

Yellow means languages with GC

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

GC is widely spread

Languages in Google Code Jam 2010 Qualifier

Yellow means languages with GC

C++ is outlier: Widely used but without GC

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

GC is widely spread

Languages in Google Code Jam 2010 Qualifier

Yellow means languages with GC

C++ is outlier: Widely used but without GC

However, C++ is the extreme multi-paradigm language. Finally, it has …

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

C++: The extreme multi-paradigm language

The next standard, aka C++0x, has

Garbage Collection

and

Reachability-Based Leak Detection

Support for

C++: The extreme multi-paradigm language

The next standard, aka C++0x, has

Garbage Collection

and

Reachability-Based Leak Detection

Support forMinimal

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

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

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

Some concepts (3)

Safely-derived pointer (value)

T *p = new T;intptr_t x = reinterpret_cast<intptr_t>(p) ^ 0x555a:T *q = reinterpret_cast<T*>(x ^ 0x555);T y = *q;

This is safely-derived pointer value

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

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

Function: get_pointer_safety()

Returns pointer-safety of the implementation

relaxed:

preferred:

strict:

Behavior does not depend on whether the value is safely-derived pointer, like as C++03• relaxed and preferred are implementation-

defined• In the case of “preferred”, there may be

leak detector• In VC2010, relaxed is always returned

and the other functions has no-effect.

Undefined behavior when dereferencing or deallocating via not safely-derived pointer value which declare_reachable(), as described later, is not called for.

Strict pointer safety

Safely-derived pointer (value)

T *p = new T;intptr_t x = reinterpret_cast<intptr_t>(p) ^ 0x555a:T *q = reinterpret_cast<T*>(x ^ 0x555);T y = *q;

This is safely-derived pointer value

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

Undefined behavior

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

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)

Usage of (un)declare_reachable()

Why needed?

T *p = new T;intptr_t x = reinterpret_cast<intptr_t>(p) ^ 0x555a:T *q = reinterpret_cast<T*>(x ^ 0x555);T y = *q;

This is safely-derived pointer value

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

Undefined behavior

A GC at label a might reclaim the object designated by p ???

Usage of (un)declare_reachable()

Why needed?

T *p = new T;intptr_t x = reinterpret_cast<intptr_t>(p) ^ 0x555a:T *q = reinterpret_cast<T*>(x ^ 0x555);T y = *q;

This is safely-derived pointer value

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

Undefined behavior

A GC at label a might reclaim the object designated by p Optimizationissue

Usage of (un)declare_reachable()

Why needed?

p is not used afterwards

NOTE: p, x, q can be assigned to the same register-> the value p does not exist anywhere at the label a-> the object designated by p (and q) can be collected by GC!!-> *q causes undefined behavior

x is not used afterwards

A GC at label a might reclaim the object designated by p Optimizationissue

T *p = new T;intptr_t x = reinterpret_cast<intptr_t>(p) ^ 0x555a:T *q = reinterpret_cast<T*>(x ^ 0x555);T y = *q;

Usage of (un)declare_reachable()

Correct code in C++0x

T *p = new T;declare_reachable(p); // Call before disguisingintptr_t x = reinterpret_cast<intptr_t>(p) ^ 0x555a:// T z = *reinterpret_cast<T*>(x ^ 0x555); // Legal// Call undeclare_reachable() after disguisingT *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.

*p isreachable=Ignored by GC

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 usingdeclare_reachable() / undeclare_reachable()

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++ Standardhttp://www.hpl.hp.com/techreports/2009/HPL-2009-360.pdf