HewlettPackard / mpgc

Multi-Process Garbage Collector

Geek Repo:Geek Repo

Github PK Tool:Github PK Tool

Add fast_gc_ptr<T>

EvanKirshenbaum opened this issue · comments

[imported from HPE issue 233]

Lokesh pointed out today [6/13/16] that we don't actually need a write barrier when assigning pointers on the stack. So we proposed a fast_gc_ptr<T> that doesn't use it. We can use the same trick as with external_gc_ptr<T> to prevent them from being put inside of GC-allocatable or GC-friendly objects. (i.e., a static_assert failure on creating the descriptor). Atomics would be equivalent to atomic<offset_ptr<T>>.

Thinking about it some more, it might be worthwhile to have a single class template for at least normal and fast GC pointers, possibly also for external ones, so that the code would only have to be written once.

From @lokeshgidra:

A very important note: We have to use normal gc_ptr in external_gc_ptr. This is because there is a possibility that a new object (allocated white), assigned to an external_gc_ptr might be used to create a stack reference to the object (after the stack is scanned in async phase) and deleting the external_gc_ptr (before the inbound table is scanned by GC thread in the async phase). This will end up having an object not getting marked till the end and will cause problems.

One way of resolving this issue even while using fast_gc_ptr in the external_gc_ptr is to scan stacks twice. However, after discussion with @evan-kirshenbaum, it was agreed to use normal gc_ptr in the external_gc_ptr as they are modified only twice: null->ptr and ptr->null.