Go, D, and the GC

[rsw0x via Digitalmars-d]

On Sunday, 4 October 2015 at 21:01:45 UTC, Jonathan M Davis wrote:
> 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

Most of these issues are addressed by fleshing out shared, it was 
already put as a 'priority' last year by Andrei but nothing was 
ever done.

If you design a language around having a GC, but do not provide 
GC friendly mechanisms, the GC will never be good for the 
language. Java would never have a GC better than a simple mark 
and sweep GC if it didn't provide help to the GC.
Designing shared around the GC just happens to be a way to do it 
without affecting the runtime performance of D at all unlike e.g, 
pointer barriers. If D has no intentions of aiding the GC, then 
the GC should just be dropped because it's basically just 
slapping Boehm on C++ right now.

bye.