I'm somewhere between a light GC user and a @nogc user, and I don't really know much about where we're at, or much about start-of-the-art GC in general.

I read comments like this: https://www.reddit.com/r/programming/comments/acsg61/version_20840_of_dmd_the_d_reference_compiler_has/edbhgzi

"""
And so we do nothing and D continues to languish as every thread is
filled with discussion about a poor implementation of a sorely
outdated GC? Other languages in this domain get by just fine - Go and
Nim to name some off the top of my head (with the full disclosure that
the former isn't quite D performance and Nim uses a thread-local GC).
There are C / C++ libraries that provide a better GC. D's tradeoff is
basically having one of the worst GCs of any language I've used this
century to avoid a write barrier that causes a, what, 5%
nigh-deterministic overall reduction in performance (assuming we use
fast barriers out of a cycle).

And if a reasonably performant GC is fundamentally incompatible and
you think it will always be this way, then maybe D as a language needs
to make serious re-evaluations? D keeps saying "Don't Fear the
Reaper", but D is one of the only languages where I actually do.
"""

How much truth is in here?
What is this business about write barriers making the GC fast? Is that
actually fact, or are there other hurdles?

Is the claim that write-barriers generally slow your runtime
performance significant? And if it is, is it possible/reasonable to
control the places where they are emit?
Can @nogc be used to inhibit write barriers in code that we know
doesn't interact with the GC, such that we have control over that loss
of perf?

It's obvious that the quality of the GC implementation is a mental barrier to entry for many... and D has a GC, which is *attractive* to some users. Despite the fact that I don't care about the GC much personally, we do need to care about this as a group, and nobody seems to be making substantial progress.

Is progress possible, or is the hard reality that the language is just designed such to be resistant to a quality GC, while the ecosystem sadly tends to rely on it?

Where's the ARC stuff? What happened to opAddRef/opRelease?

On Saturday, 5 January 2019 at 22:05:19 UTC, Manu wrote:
> Is progress possible, or is the hard reality that the language is just designed such to be resistant to a quality GC, while the ecosystem sadly tends to rely on it?
>
> Where's the ARC stuff? What happened to opAddRef/opRelease?

As per Andrei's talk at the last Dconf, ref counting requires __mutable to play nicely with const and immutable.

On Sat, 05 Jan 2019 14:05:19 -0800, Manu wrote:
> I'm somewhere between a light GC user and a @nogc user, and I don't really know much about where we're at, or much about start-of-the-art GC in general.

I use the GC unabashedly and only try to make sure I reuse memory when it's reasonably convenient. I've also looked into GC a bit.

> How much truth is in here?

D uses a simple GC. Simple means easy to reason about. It's also got better tools to stress the GC less. But one thing it could get that would be interesting is a thread-local GC. (You'd have a stop-the-world phase that happened infrequently. Casting something to shared would pin it in the thread it was allocated from.) Another thing that it probably should have is a precise pointer map. For small allocations, that probably wouldn't be a net benefit -- the overhead of storing a typeinfo pointer by each allocation isn't awesome. But for mid-size arrays and larger, it could be helpful.

The Boehm collector is more advanced than D's GC. It's (at least optionally) generational with write barriers.

Go is a GC-heavy language, only a bit less so than Java, so its GC performance makes a huge difference.

> What is this business about write barriers making the GC fast? Is that actually fact, or are there other hurdles?

With D's GC, your normal operation is unimpeded; you're not running GC code at all unless you allocate. This makes it easy to reason about the GC. However, the GC must then scan all your memory to determine if you have pointers to a memory allocation.

With write barriers, any write to any piece of memory that might contain pointers can be intercepted. The fast-but-inaccurate way is to use the MMU: mark that memory readonly and set up a fault handler. The handler will mark the memory read-write and enqueue that page of memory for scanning. The GC must also maintain a graph of which pages of memory point to which other pages of memory.

> Is the claim that write-barriers generally slow your runtime performance significant? And if it is, is it possible/reasonable to control the places where they are emit?

You can control it a little. Any time you think you might possibly need to write to a pointer, you do a fake write to it in advance. An optimizing compiler might try to remove those writes, so maybe define it in assembly.

This is hideously cumbersome.

Alternatively, you could manually mark a segment of memory for the GC to clear the write barrier, and it will have to scan that region next collection.

> Can @nogc be used to inhibit write barriers in code that we know doesn't interact with the GC, such that we have control over that loss of perf?

The point of a write barrier is to record where pointers might have changed. @nogc doesn't mean that you can't change a pointer, so it can't sidestep write barriers. Not unless you want both memory leaks and use- after-free bugs.

> Is progress possible, or is the hard reality that the language is just designed such to be resistant to a quality GC, while the ecosystem sadly tends to rely on it?

Three things about D make it harder to make a good GC for it:
* unaligned pointers
* unions
* externally allocated memory (malloc and friends)

We've pretty much addressed malloc by telling people to manually add and remove malloced memory from what the GC scans. A union is pretty much just a pointer that might not be valid. Unaligned pointers just kind of suck.

On Saturday, 5 January 2019 at 22:42:11 UTC, Meta wrote:
> On Saturday, 5 January 2019 at 22:05:19 UTC, Manu wrote:
>> Is progress possible, or is the hard reality that the language is just designed such to be resistant to a quality GC, while the ecosystem sadly tends to rely on it?
>>
>> Where's the ARC stuff? What happened to opAddRef/opRelease?
>
> As per Andrei's talk at the last Dconf, ref counting requires __mutable to play nicely with const and immutable.

I'd rather have opHeadMutable than __mutable, does the same thing but doesn't subvert  the type system

On Saturday, 5 January 2019 at 23:51:53 UTC, Nicholas Wilson wrote:
> On Saturday, 5 January 2019 at 22:42:11 UTC, Meta wrote:
>> On Saturday, 5 January 2019 at 22:05:19 UTC, Manu wrote:
>>> Is progress possible, or is the hard reality that the language is just designed such to be resistant to a quality GC, while the ecosystem sadly tends to rely on it?
>>>
>>> Where's the ARC stuff? What happened to opAddRef/opRelease?
>>
>> As per Andrei's talk at the last Dconf, ref counting requires __mutable to play nicely with const and immutable.
>
> I'd rather have opHeadMutable than __mutable, does the same thing but doesn't subvert  the type system

I'm fairly dubious of adding __mutable as well, but I'm assuming the previous solution of using an AfixAllocator didn't pan out. I don't know enough about opHeadMutable to consider whether it would address the same problems.

On 1/5/2019 2:05 PM, Manu wrote:
> How much truth is in here?

There's a lot of triggering on the word "GC". At some level, it doesn't matter how good or bad the GC is, it's "GC is bad". Even if your code never calls the GC.


> What is this business about write barriers making the GC fast? Is that
> actually fact, or are there other hurdles?

Here's an explanation:

https://stackoverflow.com/questions/19154607/how-actually-card-table-and-writer-barrier-works

There are many more if you google "gc write barrier".

The penalty, of course, is extra code gets run for every write through a pointer.

The benefits exceed the penalties for a language where all dynamic allocation is done via the GC. But for D, where quite a lot of it is not, it isn't so clear. What is clear is that if you're going to compare speed with C++, having those write barriers in there is going to be a serious penalty, because they'll be there even if you don't use the GC.

> Where's the ARC stuff? What happened to opAddRef/opRelease?

Andrei, Razvan, and I have decided that the most pragmatic way forward to support reference counting is to support copy constructors ala C++. C++ is clearly successful with this approach, and Andrei/Razvan concluded that D's postblit just doesn't cut it. Razvan has a proposal for copy constructors, and an implementation PR that has fallen a bit behind his latest proposal.

On 1/5/2019 3:12 PM, Neia Neutuladh wrote:
> The Boehm collector is more advanced than D's GC. It's (at least
> optionally) generational with write barriers.

Hmm, how does the Boehm collector insert write barriers?

Back in the 90's, I implemented a collector that did write barriers by setting the page to read-only. When a write to it was executed, the resulting seg fault was captured, the write was logged, and the page was set to read-write.

It was a fabulous idea, but the problem was it was SLOWER! The operating system's dealing with seg faults and changing write permissions was execrably slow.

Some more on write barriers with LLVM:

https://llvm.org/docs/GarbageCollection.html

On Sat, 05 Jan 2019 19:46:22 -0800, Walter Bright wrote:
> On 1/5/2019 3:12 PM, Neia Neutuladh wrote:
>> The Boehm collector is more advanced than D's GC. It's (at least optionally) generational with write barriers.
> 
> Hmm, how does the Boehm collector insert write barriers?

The docs say it "provides incremental and generational collection under operating systems which provide the right kind of virtual memory support." The source code says they're using mprotect on most posix systems, vm_protect on OSX, and something on Windows.

The only other way I know of to implement a write barrier is to insert some code on every pointer write. GC-as-a-library would require you to use their pointer type instead of the builtin, and I expect most C++ devs would rather just use a reference counting pointer type instead.

> Back in the 90's, I implemented a collector that did write barriers by setting the page to read-only. When a write to it was executed, the resulting seg fault was captured, the write was logged, and the page was set to read-write.
> 
> It was a fabulous idea, but the problem was it was SLOWER! The operating system's dealing with seg faults and changing write permissions was execrably slow.

Either the speed has improved, or they're just eating the time cost.

The other side effect is that you (and the GC) have to be very careful about replacing other segfault handlers.

On 1/5/2019 8:52 PM, Neia Neutuladh wrote:
> The only other way I know of to implement a write barrier is to insert
> some code on every pointer write. GC-as-a-library would require you to use
> their pointer type instead of the builtin, and I expect most C++ devs
> would rather just use a reference counting pointer type instead.

Microsoft tried this with their "Managed C++" variant of C++, where they had two fundamental pointer types. It was a laudable effort, but failed to gain traction. D learns from that mistake :-)


> Either the speed has improved, or they're just eating the time cost.

The fact that Java/Go/etc. use inserted write gates suggest the speed hasn't improved, which leaves eating the cost.


> The other side effect is that you (and the GC) have to be very careful
> about replacing other segfault handlers.

Yeah, you can do that with a sandboxed language, but not one that is a systems programming language where users will want to use to muck about with segfault handlers themselves.