What's the go with the GC these days?

H. S. Teoh hsteoh at quickfur.ath.cx
Mon Jan 7 22:51:02 UTC 2019


On Mon, Jan 07, 2019 at 10:27:15PM +0000, Neia Neutuladh via Digitalmars-d wrote:
[...]
> To review:
> 
> When you cast to shared, the thread-local GC pins the thing as shared.
> It also finds every bit of its memory that you can reach from that
> object, the same way as if it were doing a mark/sweep collection, and
> *that* is also pinned as shared.
> 
> When you are modifying an object that's had shared cast away, you need
> to tell the GC not to run, or you need to pin
> objects-that-will-become-shared temporarily (for instance, by keeping
> local references to them).

This step is too easy to get wrong.  Once you cast shared away, the type
system can no longer help you identify it as shared (or "once was
shared").  As far as the compiler is concerned, assigning a pointer to a
thread-local object to a shared pointer that has been cast into a
thread-local pointer, is identical to assigning one thread-local pointer
to another.  So you'll run into the problem Steven described, without
any warning whatsoever.


> When you are done modifying an object that's had shared cast away, you
> need to cast it back to shared.

This is also too easy to miss, because under current D, such a cast is
redundant and not done in practice. It also looks weird:

	class C { ... }
	shared(C) myObj;

	mutex.acquire();
	C tmp = cast(C) myObj;
	tmp.doStuff();
	myObj = cast(shared(C)) tmp; // people will not think to do this
	mutex.release();


> This is not a good solution, so D isn't getting a thread-local GC that
> eliminates stop-the-world unless someone else comes up with a cleverer
> solution. On the other hand, it doesn't have a cost for casting away
> shared as such; casting shared(T) to const(T) is totally free.

Yeah, shared is the fly in the ointment that prevents us from having a
thread-local GC.

Perhaps there can be some way of detecting whether the code casts away
shared?  I mean if your code never actually casts away shared, e.g. by
using messaging or whatever for thread communication, then you won't run
into this problem, and you could safely use a thread-local GC without
any ill-effects.  Though all it takes is for *one* cast to exist
*somewhere* and your code becomes memory-unsafe.  So it cannot be
enabled by default.


T

-- 
They say that "guns don't kill people, people kill people." Well I think
the gun helps. If you just stood there and yelled BANG, I don't think
you'd kill too many people. -- Eddie Izzard, Dressed to Kill


More information about the Digitalmars-d mailing list