On Wednesday, 15 June 2016 at 13:56:09 UTC, Jack Stouffer wrote:

> One guy wrote the LuaJIT GC, which beat almost everyone else in performance when I last checked
“The current garbage collector is relatively slow compared to implementations for other language runtimes. It's not competitive with top-of-the-line GCs, especially for large workloads.“
https://github.com/LuaJIT/LuaJIT/issues/38

They have planned something for 3.0 that may or may not work:
http://wiki.luajit.org/New-Garbage-Collector
But that’s merely a design, AFAIK there’s no implementation. They’re still looking for a sponsor for that.

>> Has anyone thought about taking GC from .NET and reusing it in D?
> Two words: write barriers.
What about them? You mean not all D’s target platforms support them?

On Wednesday, 15 June 2016 at 17:03:21 UTC, Konstantin wrote:
>> Two words: write barriers.
>
> What about them? You mean not all D’s target platforms support them?

They're not acceptable for a systems programming language as they require you to pay for something that you might not use.

According to our resident GC maintainer (among many other things), they would cause a 1%-5% slow down in the language: https://github.com/dlang/druntime/pull/1081#issuecomment-69151660

On Wednesday, 15 June 2016 at 17:03:21 UTC, Konstantin wrote:
> On Wednesday, 15 June 2016 at 13:56:09 UTC, Jack Stouffer wrote:
>>> Has anyone thought about taking GC from .NET and reusing it in D?
>> Two words: write barriers.
> What about them? You mean not all D’s target platforms support them?

I think he meant that the .NET GC (and most GC designs) rely on write barriers, but D does not have write barriers, since D is meant to be a proper systems language.

On Wednesday, 15 June 2016 at 18:28:42 UTC, Edwin van Leeuwen wrote:
>
> I think he meant that the .NET GC (and most GC designs) rely on write barriers, but D does not have write barriers, since D is meant to be a proper systems language.

My reading of that LuaJIT GC document is that it requires write barriers, but that they are very cheap.

On Wednesday, 15 June 2016 at 17:02:11 UTC, rikki cattermole wrote:

> Higher level languages like Java have the benefit of using pools and optimizing for this usage pattern, D does and will never have this.
Why don't you want the same for D?

> 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.
Some areas, like compiling, or producing HTML/XML/JSON documents, manipulate strings a lot.
Other areas, like GUI editors for sufficiently complex documents, or level editors for videogame, need to efficiently manipulate huge trees of assorted small objects, not necessarily strings.

> 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.
Yeah, that’s what I regularly do in C++ when I need to efficiently create/destroys many small objects. Sure, this typically leads to the best performance, e.g. because I can make the memory layout as cache friendly as humanly possible.
But not all projects need that. And even for very performance demanding apps, not all components of the app need that.
For such cases, a good GC (that just works well out of the box like .NET's GC does) can reduce development costs significantly.

On Wednesday, 15 June 2016 at 18:48:28 UTC, jmh530 wrote:
> My reading of that LuaJIT GC document is that it requires write barriers, but that they are very cheap.

...for language that was originally VM-based. yet they'll have a noticable impact on language like D -- especially when programmer want to opt-out GC.

On Wednesday, 15 June 2016 at 18:23:52 UTC, Jack Stouffer wrote:

> They're not acceptable for a systems programming language as they require you to pay for something that you might not use.
>
> According to our resident GC maintainer (among many other things), they would cause a 1%-5% slow down in the language: https://github.com/dlang/druntime/pull/1081#issuecomment-69151660

Well I’m not sure about the 5% (MS says their write barrier overhead is comparable to the cost of a simple method call, namely 6.4ns: https://msdn.microsoft.com/en-us/library/ms973852.aspx), but yeah, there’s some tradeoff, for having a good GC.

By the way, Go implemented those barriers in version 1.5 a year ago: https://blog.golang.org/go15gc

On Wednesday, 15 June 2016 at 19:39:59 UTC, Konstantin wrote:
> On Wednesday, 15 June 2016 at 18:23:52 UTC, Jack Stouffer wrote:
>
>> They're not acceptable for a systems programming language as they require you to pay for something that you might not use.
>>
>> According to our resident GC maintainer (among many other things), they would cause a 1%-5% slow down in the language: https://github.com/dlang/druntime/pull/1081#issuecomment-69151660
>
> Well I’m not sure about the 5% (MS says their write barrier overhead is comparable to the cost of a simple method call, namely 6.4ns: https://msdn.microsoft.com/en-us/library/ms973852.aspx), but yeah, there’s some tradeoff, for having a good GC.
>
> By the way, Go implemented those barriers in version 1.5 a year ago: https://blog.golang.org/go15gc

May I point out that you do not seem to have any kind of experience
of D's GC? Try it and see for yourself wether it actually stops you
or not. It's right that not everyone is pleased with the current GC
but those users have specific expectations and I'm not certain at
all that they would find C# or Go's GC acceptable either.

The point is, D doesn't have to have a GC. Not using it is way easier
than in most other languages because all the tools to help you
profile it and avoid it are provided by the compiler. Go without a
good GC is a dead language. D without a good GC is just not as good
as it could be. And btw we're generally faster than Go ;-)

The point is: while a better GC is a work in progress we'll *never*
have a GC that can fit all needs, but it's not as critical as it is
in Go or in C# because we provide other ways to manage memory when
limitations arise.

On Wednesday, 15 June 2016 at 18:48:28 UTC, jmh530 wrote:
> On Wednesday, 15 June 2016 at 18:28:42 UTC, Edwin van Leeuwen wrote:
>>
>> I think he meant that the .NET GC (and most GC designs) rely on write barriers, but D does not have write barriers, since D is meant to be a proper systems language.
>
> My reading of that LuaJIT GC document is that it requires write barriers, but that they are very cheap.

Problem is, in D, many people want to NOT use a GC, and this is something we want to support. These people also do NOT want to pay for write barrier they do not use.

That being said, we can do write barrier leveraging MMU on immutable (it'd be too expensive to do it on mutable data) during collection only, so that people that do not want to use the GC do not pay for it. The technique is used successfully in the ML family of languages for ages now with great results.

Generally, I think the right path forward for D's GC is not to emulate managed language's GC as this clearly won't be acceptable for many users. On the other hand,
we should:
1/ Leverage D's type system as to get infos about mutability/thread locality and segregate the heap accordingly/use adapted technique for each.
2/ Make sure the GC can deliver malloc grade performance in an alloc/free scenario, as to enable hybrid approach and allow people to rely on the GC to the extent they are willing to pay for. jemalloc internal datastructures are very amendable to build a GC.

I started using this approach in SDC's GC. The only thing preventing me to move faster here is simply the time I can allocate to solve that problem.

On Wednesday, 15 June 2016 at 19:39:59 UTC, Konstantin wrote:
> Well I’m not sure about the 5% (MS says their write barrier overhead is comparable to the cost of a simple method call, namely 6.4ns: https://msdn.microsoft.com/en-us/library/ms973852.aspx), but yeah, there’s some tradeoff, for having a good GC.

Even 1% overhead is unacceptable. Again, it's not reasonable for a systems language to have people pay for things they're not using.

Write barriers will come to D over Walter's dead body.

> By the way, Go implemented those barriers in version 1.5 a year ago: https://blog.golang.org/go15gc

Go has no allocation strategies but the GC, so that point is moot.