The new GC in Go 1.5 seems interesting. What they say about is certainly interesting.

http://blog.golang.org/go15gc

"To create a garbage collector for the next decade, we turned to an algorithm from decades ago. Go's new garbage collector is a concurrent, tri-color, mark-sweep collector, an idea first proposed by Dijkstra in 1978."

On Friday, 18 September 2015 at 19:26:27 UTC, Rory wrote:
> The new GC in Go 1.5 seems interesting. What they say about is certainly interesting.
>
> http://blog.golang.org/go15gc
>
> "To create a garbage collector for the next decade, we turned to an algorithm from decades ago. Go's new garbage collector is a concurrent, tri-color, mark-sweep collector, an idea first proposed by Dijkstra in 1978."

I think this was talked about in general. If I remember correctly the consensus was that

1. D's GC is really primitive (70's style stop the world) and there's a lot of room for improvement

2. However, D has much more important problems currently than a slow GC, e.g. std.allocator, a GC-less phobos, smaller .o files for embedded systems, A better DMD with DDMD, etc.

The reason Go has a better GC than D is that Go users have no choice but to use the GC, while D users have a bunch more options.

On 18-Sep-2015 23:46, Jack Stouffer wrote:
> On Friday, 18 September 2015 at 19:26:27 UTC, Rory wrote:
[snip]
> The reason Go has a better GC than D is that Go users have no choice but
> to use the GC, while D users have a bunch more options.

To put it differently - D is a big language that has lots of things to improve/extend whereas Go is simplistic. This means the focus of the Go team is on run-time only for a while now, while we keep on improving the core language together with the druntime.

-- 
Dmitry Olshansky

On Friday, 18 September 2015 at 19:26:27 UTC, Rory wrote:
> The new GC in Go 1.5 seems interesting. What they say about is certainly interesting.
>
> http://blog.golang.org/go15gc
>

Go 1.6 GC roadmap:

https://docs.google.com/document/d/1kBx98ulj5V5M9Zdeamy7v6ofZXX3yPziAf0V27A64Mo/preview

On Friday, 18 September 2015 at 19:26:27 UTC, Rory wrote:
> The new GC in Go 1.5 seems interesting. What they say about is certainly interesting.

They went the way of classical GC-ed language where write barriers are used actively, allowing to make concurrent, incremental and (eventually, if not yet) generational GC. However it has a cost - pointer field updates are slower than in plain C/C++/D, and overall speed is close to Java. D tries to be like C and C++ where simple code is fast and straightforward, there are no write barriers and there will never be, without changing the language design. It means D's GC will always be dog slow - it has to stop the world and scan full heap every time. And that leads to different usage pattern where GC heap should remain small and GC allocation rate low.

On Saturday, 19 September 2015 at 08:36:51 UTC, thedeemon wrote:
> full heap every time. And that leads to different usage pattern where GC heap should remain small and GC allocation rate low.

Please, let's stop pretending you only have to scan the GC heap. You have to scan all pointers that somehow can lead to something that can lead to something... that points into the GC heap.

To get out of that you need a language constructs that create a verified separation between pointers that can and pointers that cannot reach GC pointers.

That's very hard to do, especially since D does not have GC pointers.

The impression I got reading the article was that their GC was very much like our current one except that the marking part of the algorithm was run concurrently.

That is the only reason I shared the article. To me it seems one should be
to mark variables/types with which style of memory management it should
use. I suppose that is what allocators are becoming.
Perhaps someone will write a concurrent generational garbage collected
allocator.

On Sat, Sep 19, 2015 at 10:36 AM, thedeemon via Digitalmars-d-announce < digitalmars-d-announce@puremagic.com> wrote:

> On Friday, 18 September 2015 at 19:26:27 UTC, Rory wrote:
>
>> The new GC in Go 1.5 seems interesting. What they say about is certainly interesting.
>>
>
> They went the way of classical GC-ed language where write barriers are used actively, allowing to make concurrent, incremental and (eventually, if not yet) generational GC. However it has a cost - pointer field updates are slower than in plain C/C++/D, and overall speed is close to Java. D tries to be like C and C++ where simple code is fast and straightforward, there are no write barriers and there will never be, without changing the language design. It means D's GC will always be dog slow - it has to stop the world and scan full heap every time. And that leads to different usage pattern where GC heap should remain small and GC allocation rate low.
>
>

On Saturday, 19 September 2015 at 14:12:10 UTC, Rory McGuire wrote:
> The impression I got reading the article was that their GC was very much like our current one except that the marking part of the algorithm was run concurrently.

It is quite different. As mentioned they also protect writes to pointers with GC semantics. In D this will be very difficult to get right due to the unsafe regions (e.g. inline asm etc).

Go has a compiler backend tailored to their semantics.

On Saturday, 19 September 2015 at 09:22:40 UTC, Ola Fosheim Grøstad wrote:

> Please, let's stop pretending you only have to scan the GC heap. You have to scan all pointers that somehow can lead to something that can lead to something... that points into the GC heap.

Yes, good point. One should keep root ranges small too.
If we carefully use addRoot() and addRange() for data directly pointing to GC heap I think we don't need to let GC scan everything that can lead to this data. This is error-prone in general, of course.

On Saturday, 19 September 2015 at 17:56:23 UTC, thedeemon wrote:
> Yes, good point. One should keep root ranges small too.
> If we carefully use addRoot() and addRange() for data directly pointing to GC heap I think we don't need to let GC scan everything that can lead to this data. This is error-prone in general, of course.

Yes, it is error prone when the project grows over time. And even if it looks like it is working one may forget to remove the addRoot() and then we have a leak. Move semantics could help of course (addRoot in constructor).

But it also makes the transition between GC/non-GC slower. E.g. as long as you keep a scanned pointer on the stack then addRoot() isn't needed. As long as you know that the object remains included in the GC graph, you also don't need addRoot().

But compiler support is needed to ensure that that either the GC graph remains connected or that the pointer actually is pushed to the stack before the object is collected and the stack is scanned. Lots of details that must be right.

I'm not sure if the current collector scans all registers, or just scans the stack? If it only scans the stack then you need to lock out the GC collection process between obtaining a pointer and pushing the pointer on the stack or adding the root.