Go, D, and the GC

[Jonathan M Davis via Digitalmars-d]

On Sunday, 4 October 2015 at 17:30:39 UTC, rsw0x wrote:
> I still say it's worth investigating a thread-local GC by 
> taking advantage of the fact that shared has never really been 
> properly fleshed out. This would heavily play to D's TLS by 
> default, and preferring message passing over shared data.

That would be ideal but gets really nasty for a number of reasons 
- primarily having to do with casting. It's perfectly possible to 
cast to and from shared and much easier to create something as 
thread-local and then cast it to shared than to create it as 
shared, so you very quickly run into problems with objects being 
created on heap but really needing to be used on another. Another 
major issue is message passing, because in order to avoid 
copying, you basically need a way to move an object from one 
thread-local heap to another. Right now the way you'd do it is to 
cast to immutable to pass the object and cast it back to mutable 
on the other side (which is _far_ from ideal). Using shared would 
be better, but the last time I checked, Variant has issues with 
it so that that didn't work with std.concurrency. Regardless, the 
fact that you're casting to pass across threads again runs into 
issues with objects being created on a particular heap but then 
needing to be moved to another. _Maybe_ that could be resolved by 
making casting to and from shared do a lot more work underneath 
the hood, but that get's _really_ complicated when you start 
having objects that refer to other objects and the like.

So, having a thread-local GC _sounds_ like a great idea, but it's 
not at all clear that we can actually pull it off given how much 
you're allowed to do in D. There can be some serious downsides to 
not placing major restrictions on the user like languages like 
Java or Go tend to do.

- Jonathan M Davis