RFC: Pinning interface for the GC

[Alex Rønne Petersen]

On 13-10-2012 21:51, David Nadlinger wrote:
> On Saturday, 13 October 2012 at 19:34:29 UTC, Alex Rønne Petersen wrote:
>> As for your question: Not quite. A pinned object that points to any
>> other unpinned objects will implicitly keep those alive. This is at
>> least how I would expect it to work, following the principle of least
>> surprise.
>
> But then the GC _does_ have to scan those objects to be able to mark the
> whole graph as live, no? Wasn't it this what you were referring to as
> "kind of terrible" in your first post?

Ah, I could have been clearer here.

The problem with using roots is two-fold:

1) It adds unnecessary work for the marking phase.
2) It forces scanning of 'pinned' objects to be imprecise.

(1) is not so much of a problem (it only happens if you have root ranges 
with null pointers and so on), but (2) can be.

Another problem that would pop up if we made scanning of roots precise 
is that, then, the stored reference could be moved (as you also pointed 
out).

I guess there is also the issue of adding roots being a relatively 
expensive operation - it has to go through a mutex-guarded function 
whereas pinning objects can be made lock-free (at least on some 
architectures).

I think the problem boils down to using roots for something they're not 
meant to be used for, semantically.

>
> But yes, for a moving GC, a way to pin objects would have to be added,
> and lots of code using GC.add*() for interfacing with C would have to be
> changed – or we make those functions actually pin the objects for
> backwards compatibility and add a new set of functions which really just
> add something as a root.
>
> David

-- 
Alex Rønne Petersen
alex at lycus.org
http://lycus.org