Started learning D. Like the language. However, found several people complaining about garbage collector’s reliability and performance. For me it’s a showstopper.

I don’t believe a community is capable of creating a good GC. It’s just too complex engineering task. It’s been a known problem for years, still no solution.

Since recently, Microsoft’s .NET framework and runtime are open source under MIT license. Here’s the main parts of their GC:  https://github.com/dotnet/coreclr/tree/master/src/gc As you see, it’s in C++, and contains 10-20 times more code, then D’s GC. Theoretically, it should be cross-platform: there’re build instructions for Linux (including ARM), OSX, and BSD; but I haven’t tried building on those.

Has anyone thought about taking GC from .NET and reusing it in D?

That GC is very efficient for wide range of applications. I’ve been using .NET since 3.0 on desktops, servers, embedded and mobiles, never had issues with GC, it just works, and the performance is good.

I don‘t know architectural details of either GC.

I perfectly aware it might happen so they are completely incompatible, or very hard to port: because .NET’s System.Object vs. D’s Object differences; because D’s fibers or just very different threading model; because different CRT; many other reasons possible.

But if we’re lucky, this GC could lead to a great improvement for D ecosystem, not costing too much time. IMO that is something doable by a single person in a spare time.

Thoughts?

On Wednesday, 15 June 2016 at 13:19:31 UTC, Konstantin wrote:
> Started learning D. Like the language. However, found several people complaining about garbage collector’s reliability and performance. For me it’s a showstopper.
>

Possible to disable.

> I don’t believe a community is capable of creating a good GC. It’s just too complex engineering task. It’s been a known problem for years, still no solution.
>

They've got a GSOC guy workin' on it now. I would hold off judgements until that effort is concluded.

>
> Has anyone thought about taking GC from .NET and reusing it in D?
>

I don't think this would work, but I don't know enough to be able to explain why.

I'm not sure how much you know about D but:

1. Somebody is working on improving D's GC as part of GSOC in the hopes of making it able to be precise (from memory not 100% sure).
2. Only a few language features forces you to use the GC.
3. For most uses you are not forced to use the GC in any form especially with the help of std.experimental.allocator.
4. Our GC is based upon the Boehm GC. Its old. Even the more recent versions would be far better then what we have (we forked a long time ago).
5. The requirements for our GC is quite intricate. I.e. you can't just pop in one that doesn't understand about our Thread Local Storage (TLS) and stuff.
6. As said by somebody else we can disable the GC so it won't go ahead and scan upon allocation (only time it does).

On Wednesday, 15 June 2016 at 13:19:31 UTC, Konstantin wrote:
> Has anyone thought about taking GC from .NET and reusing it in D?

Fast GC for D was considered and rejected. What can be done is a precise and concurrent GC.

On Wednesday, 15 June 2016 at 13:19:31 UTC, Konstantin wrote:
> I don’t believe a community is capable of creating a good GC.

you are wrong. and you definitely know nothing about garbage collection, virtual machines and code generation. i wonder why people keep coming with "suggestions" and "solutions" without even a small knowledge in problem field.

On 16/06/2016 1:33 AM, rikki cattermole wrote:
> I'm not sure how much you know about D but:
>
> 1. Somebody is working on improving D's GC as part of GSOC in the hopes
> of making it able to be precise (from memory not 100% sure).
> 2. Only a few language features forces you to use the GC.
> 3. For most uses you are not forced to use the GC in any form especially
> with the help of std.experimental.allocator.
> 4. Our GC is based upon the Boehm GC. Its old. Even the more recent
> versions would be far better then what we have (we forked a long time ago).
> 5. The requirements for our GC is quite intricate. I.e. you can't just
> pop in one that doesn't understand about our Thread Local Storage (TLS)
> and stuff.
> 6. As said by somebody else we can disable the GC so it won't go ahead
> and scan upon allocation (only time it does).

I forgot to mention, good D code is not the same as a higher level language like Java.

Here you don't have the automagick behavior of arrays. If you append it will have a high cost. All allocations have a large cost. Instead allocate in one large block which will of course be a whole lot faster then small tiny ones.

So even if the GC is enabled, good D code won't cause too much slow down unless you decide to write heavy OOP code.

On Wednesday, 15 June 2016 at 13:19:31 UTC, Konstantin wrote:
> I don’t believe a community is capable of creating a good GC. It’s just too complex engineering task. It’s been a known problem for years, still no solution.

GCs are a solved problem and the most common and fastest techniques have been known for more than 20 years. The GC implementation that D is using now came from the 70's, for example.

One guy wrote the LuaJIT GC, which beat almost everyone else in performance when I last checked, so I think this is a massive exaggeration.

> Has anyone thought about taking GC from .NET and reusing it in D?

Two words: write barriers.

On Wednesday, 15 June 2016 at 13:27:47 UTC, jmh530 wrote:

> Possible to disable.
I don’t want to: for the last couple years I’ve been developing 50/50 C++/C#, and I admit I’m usually more productive using C#, one of the reasons of that is GC.

> They've got a GSOC guy workin' on it now. I would hold off judgements until that effort is concluded.
OK let's see.

On Wednesday, 15 June 2016 at 13:40:11 UTC, rikki cattermole wrote:

> 5. The requirements for our GC is quite intricate. I.e. you can't just
> pop in one that doesn't understand about our Thread Local Storage (TLS)
> and stuff.
D’s TLS that different from .NET's TLS? https://msdn.microsoft.com/en-us/library/system.threadstaticattribute(v=vs.110).aspx

> I forgot to mention, good D code is not the same as a higher level language like Java.
> Here you don't have the automagick behavior of arrays. If you append it will have a high cost. All allocations have a large cost. Instead allocate in one large block which will of course be a whole lot faster then small tiny ones.
You’re saying memory allocations in D are generally very expensive, but that’s not a problem, because it already functions as designed?

> So even if the GC is enabled, good D code won't cause too much slow down unless you decide to write heavy OOP code.
I’ve been developing heavy OOP code in various languages (mostly C++, but also C# and Objective-C) for decades already. OOP works very well for me.

On 16/06/2016 4:52 AM, Konstantin wrote:
> On Wednesday, 15 June 2016 at 13:40:11 UTC, rikki cattermole wrote:
>
>> 5. The requirements for our GC is quite intricate. I.e. you can't just
>> pop in one that doesn't understand about our Thread Local Storage (TLS)
>> and stuff.
> D’s TLS that different from .NET's TLS?
> https://msdn.microsoft.com/en-us/library/system.threadstaticattribute(v=vs.110).aspx

Yes it most definitely is.
We roll our own for platforms that do not support it.

There is an abstraction in druntime specifically to handle this problem.

>> I forgot to mention, good D code is not the same as a higher level
>> language like Java.
>> Here you don't have the automagick behavior of arrays. If you append
>> it will have a high cost. All allocations have a large cost. Instead
>> allocate in one large block which will of course be a whole lot faster
>> then small tiny ones.
> You’re saying memory allocations in D are generally very expensive, but
> that’s not a problem, because it already functions as designed?

No.
Memory allocations are /always/ expensive.

Higher level languages like Java have the benefit of using pools and optimizing for this usage pattern, D does and will never have this.

Keep in mind an allocation = usage of malloc + write to returned pointer.

>> So even if the GC is enabled, good D code won't cause too much slow
>> down unless you decide to write heavy OOP code.
> I’ve been developing heavy OOP code in various languages (mostly C++,
> but also C# and Objective-C) for decades already. OOP works very well
> for me.

Well if you really insist to have a String class don't be too surprised for some reason it doesn't have the same performance to say Java.
Aka don't go around creating/destroying classes a huge amount unless you have rolled some form of memory management policy such as reserving memory for the GC to use.

We have other tools where OOP normally would be used such as templates, structs, function pointers and delegates.