What's the go with the GC these days?

[Neia Neutuladh]

On Mon, 07 Jan 2019 11:52:18 -0800, H. S. Teoh wrote:
> I think what Neia has in mind, which he mentioned in another post, is to
> have the druntime function simply pin the object, whichever pool it
> belongs to.  The idea being to tell the respective thread-local GC "this
> object might be referenced by another thread, do not collect or move".

She, not he.

Thinking about this some more, this strategy isn't as cheap or easy as I 
was hoping. Let's say you're using fearless:

auto a = gcExclusive!Node;
spawn({
  {
    auto tmp = a.lock;
    tmp.parent = new Object;
  }
  GC.threadLocal.collect();
  GC.threadLocal.minimize();
  {
    auto tmp = a.lock;
    writeln(tmp.parent.toString);
  }
});

Where do we insert the runtime call to mark a.parent as shared? Fearless 
would have to:
1. Acquire the mutex
2. Tell the current thread's GC to add the locked object as a root
3. Run your code
4. Tell the thread's GC to pin everything it can find from `a` (by casting 
back to shared)
5. Release the mutex

This effectively incurs a mark (but not sweep) cycle every time you cast 
to shared. If it were just pinning one object, that would be a lot easier 
to sell.