Hi Guys,

I know that Go invested many time and resources in an implementation of a good GC. And they keep working on it, e.g. https://github.com/golang/proposal/blob/master/design/12800-sweep-free-alloc.md

I also see that the implementation is licensed as BSD, as far as I see: https://github.com/golang/go/blob/master/LICENSE

Question: is it possible to make a D compiler/runtime that uses Go's GC? Wouldn't it largely benefit D? I guess that I'm not the first one to think about it. Thoughts?

On 01-Oct-2015 12:33, Tourist wrote:
> Hi Guys,
>
> I know that Go invested many time and resources in an implementation of
> a good GC. And they keep working on it, e.g.
> https://github.com/golang/proposal/blob/master/design/12800-sweep-free-alloc.md
>
>
> I also see that the implementation is licensed as BSD, as far as I see:
> https://github.com/golang/go/blob/master/LICENSE
>
> Question: is it possible to make a D compiler/runtime that uses Go's GC?

***memory barriers for pointer writes***

I guess not w/o huge amount of work.

> Wouldn't it largely benefit D? I guess that I'm not the first one to
> think about it. Thoughts?


-- 
Dmitry Olshansky

On 01/10/15 10:33 PM, Tourist wrote:
> Hi Guys,
>
> I know that Go invested many time and resources in an implementation of
> a good GC. And they keep working on it, e.g.
> https://github.com/golang/proposal/blob/master/design/12800-sweep-free-alloc.md
>
>
> I also see that the implementation is licensed as BSD, as far as I see:
> https://github.com/golang/go/blob/master/LICENSE
>
> Question: is it possible to make a D compiler/runtime that uses Go's GC?
> Wouldn't it largely benefit D? I guess that I'm not the first one to
> think about it. Thoughts?

We could probably adapt Go's GC to D. But there may not be much point to it.

Go and D have very different architectures and styles. Because of this the way data and hence memory is created and consumed is different.

Go's GC would have been optimized for Go's patterns and usage of it.
We could however read and learn from how it works. But again, we do have some pretty innovate technologies here. They just don't reach druntime. Which is a shame.

On Thursday, 1 October 2015 at 09:40:09 UTC, Rikki Cattermole wrote:
> Go's GC would have been optimized for Go's patterns and usage of it.

It's JIT, which usually gets optimized for patterns, the GC pattern is generic: collect the garbage and do it fast.

On Thursday, 1 October 2015 at 09:33:26 UTC, Tourist wrote:
> Hi Guys,
>
> I know that Go invested many time and resources in an implementation of a good GC. And they keep working on it, e.g. https://github.com/golang/proposal/blob/master/design/12800-sweep-free-alloc.md
>
> I also see that the implementation is licensed as BSD, as far as I see: https://github.com/golang/go/blob/master/LICENSE
>
> Question: is it possible to make a D compiler/runtime that uses Go's GC? Wouldn't it largely benefit D? I guess that I'm not the first one to think about it. Thoughts?

This topic was discussed here: http://forum.dlang.org/thread/iohdxjqvcetesloxbwfh@forum.dlang.org

On Thursday, 1 October 2015 at 09:48:57 UTC, Kagamin wrote:
> On Thursday, 1 October 2015 at 09:40:09 UTC, Rikki Cattermole wrote:
>> Go's GC would have been optimized for Go's patterns and usage of it.
>
> It's JIT,
no?
> which usually gets optimized for patterns, the GC pattern is generic: collect the garbage and do it fast.

No, no it's not. Go's GC has a massive overhead because it's intended to have low latency because that's what Go programs typically require.
Go's GC is actually pretty slow by design.

On 1 Oct 2015 11:35 am, "Tourist via Digitalmars-d" < digitalmars-d@puremagic.com> wrote:
>
> Hi Guys,
>
> I know that Go invested many time and resources in an implementation of a
good GC. And they keep working on it, e.g. https://github.com/golang/proposal/blob/master/design/12800-sweep-free-alloc.md
>
> I also see that the implementation is licensed as BSD, as far as I see:
https://github.com/golang/go/blob/master/LICENSE
>
> Question: is it possible to make a D compiler/runtime that uses Go's GC?
Wouldn't it largely benefit D? I guess that I'm not the first one to think about it. Thoughts?

Why do you think Go's GC might be better than D's?  Is it because we lack the PR when changes/innovations are done to the GC in druntime?  Do you *know* about anything new that has changed or improved in D's GC over the last two years?

I'd be interested to hear about this.

On Friday, 2 October 2015 at 01:21:15 UTC, rsw0x wrote:
> No, no it's not. Go's GC has a massive overhead because it's intended to have low latency because that's what Go programs typically require.
> Go's GC is actually pretty slow by design.

Low latency (also a synonym for fast) is required by interactive applications like client and server software, not by Go itself. Partially interactive data processing programs like compilers prefer optimization for total execution time. GC improvements can show in both scenarios, can depend on usage profile.

On Friday, 2 October 2015 at 06:53:56 UTC, Iain Buclaw wrote:
> On 1 Oct 2015 11:35 am, "Tourist via Digitalmars-d" < digitalmars-d@puremagic.com> wrote:
>> [...]
> good GC. And they keep working on it, e.g. https://github.com/golang/proposal/blob/master/design/12800-sweep-free-alloc.md
>> [...]
> https://github.com/golang/go/blob/master/LICENSE
>> [...]
> Wouldn't it largely benefit D? I guess that I'm not the first one to think about it. Thoughts?
>
> Why do you think Go's GC might be better than D's?  Is it because we lack the PR when changes/innovations are done to the GC in druntime?  Do you *know* about anything new that has changed or improved in D's GC over the last two years?
>
> I'd be interested to hear about this.

I know that it has the reputation of being of the simplest kind. Haven't looked at the code actually (and I wouldn't understand much even if I did).

On 2 Oct 2015 1:32 pm, "Tourist via Digitalmars-d" < digitalmars-d@puremagic.com> wrote:
>
> On Friday, 2 October 2015 at 06:53:56 UTC, Iain Buclaw wrote:
>>
>> On 1 Oct 2015 11:35 am, "Tourist via Digitalmars-d" <
digitalmars-d@puremagic.com> wrote:
>>>
>>> [...]
>>
>> good GC. And they keep working on it, e.g.
https://github.com/golang/proposal/blob/master/design/12800-sweep-free-alloc.md
>>>
>>> [...]
>>
>> https://github.com/golang/go/blob/master/LICENSE
>>>
>>> [...]
>>
>> Wouldn't it largely benefit D? I guess that I'm not the first one to
think about it. Thoughts?
>>
>> Why do you think Go's GC might be better than D's?  Is it because we
lack the PR when changes/innovations are done to the GC in druntime?  Do you *know* about anything new that has changed or improved in D's GC over the last two years?
>>
>> I'd be interested to hear about this.
>
>
> I know that it has the reputation of being of the simplest kind. Haven't
looked at the code actually (and I wouldn't understand much even if I did).

So I doubt you've looked at Go's GC code either.  In which case it is a matter of PR which led to your suggestion.