Write barriers

[quickfur]

One of the major blockers for a better GC in D is the fact that Walter downright rejects pointer write barriers. This immediately excludes a large percentage of competitive, modern GC algorithms, forcing D to be stuck with a stop-the-world mark-and-sweep GC.

I think it's time to reevaluate this option. Introducing pointer write barriers, maybe initially via an optional compiler switch, would allow us to experiment with more modern GCs like incremental algorithms, that would, at least partially, address the concerns of the GC naysayers. Having a more modern GC algorithm will also make this fork more competitive and be viable in more applications. (And perhaps, hopefully, force the hand of upstream to get past the blockade of no write barriers? One can hope...) D's current GC is actually not bad, but why not make it even better by removing one of the biggest blockades?

[quickfur]

A less extreme alternative of write barriers to all pointers would be write barriers to pointers that cross the TLS boundary.

Maybe this is where we can make share more meaningful than what it currently is in D: pointers will be TLS by default, but when you write to a shared pointer there will be a write barrier to inform the GC of a pointer crossing the TLS boundary. Then we can have per-thread GC instances that will not block other threads, and a global GC to take care of the shared pointers that cross thread boundaries. This could possibly be a lower-effort implementation for the near future, rather than a full-out incremental GC algorithm that will require significant time/effort investment to pull off successfully.

[IgorDeepakM]

Will this work with a fully concurrent GC?

[quickfur]

Don't know. But it will definitely open up more possibilities than we currently have. Most contemporary incremental GC algorithms require write barriers of some kind. Being free of the constraint of no-write-barriers will open the door for us to explore these options that were previously not possible.

[adamdruppe]

Walter has actually softened his stance: he's open to write barriers now as an experimental switch. But he's not likely to implement it himself any time soon (probably in part because he doesn't know how to do it in a useful way).

But yeah, I agree we should look into it. I don't know how to implement it either though. BTW Amaury has been working on a new GC for upstream and I'm very optimistic about it. It keeps the same interface but has several quality of implementation fixes. He's mostly doing it in his sdc compiler but there are concrete plans in the work to upstream it to dmd.

[quickfur]

Cool stuff. Which also means we probably shouldn't introduce too many breaking changes in the meantime so that his new GC can be merged in without too much hassle!

[quickfur]

Also, I don't think there's any one universal write barrier implementation... what you do in the write barrier depends on what the associated GC implementation needs. So the exact implementation is going to depend very much on which GC algorithm we're targeting. (For performance reasons, you probably do not want the write barrier to be a function call... or worse, an indirect function call hook set by the GC at runtime. I mean it would work, but would come with a big performance penalty. As much as possible the choice should be made at compile-time.)

But a first step would be making it as least possible to have write barriers in the compiler. Some careful thought would have to be put to this to make it work correctly.

[quickfur]

Also, when to insert a write barrier and when it can be elided, which will be important for good performance, will also depend greatly on the choice of GC algorithm. So we're pretty much forced to decide this at compile-time, or pay a pretty big performance penalty.

[adamdruppe]

What I had in mind for write barriers is it just emits, instead of a mov [thing], other;it des like _d_writePointer(void** dst, void* src); and then the library can hook it and take it from there. would prolly murder performance but you never know, inliners can do magical things

[quickfur]

The problem is that inliners work at compile-time, not runtime. No matter what, you still have to know which GC algorithm you're using at compile-time. The only way this can be deferred to runtime is if every write barrier makes a function call, and the function call is redirected at runtime to whatever GC is chosen at runtime. This will come with a huge performance penalty.

[IgorDeepakM]

Either way I'm for anything that releases out of the GC jail. Another possibility I've been thinking about is making classes a GC type that inserts write barriers and all other raw pointers will not insert them. This is however not compatible with old code if you want to test that. Otherwise I think a compiler would be just fine for experimenting.

In the long run, if any of this going to viable there must be a separation between raw pointers and managed pointers. I cannot see any other way around this problem. There is no way that the compiler can distinguish them otherwise. Let's say that manual memory is the most unusual type of pointer, then just a RawPtr!Type template could work and the compiler doesn't insert any instrumentation code.

The true goal for me would if we could remove raw pointers (like int* p) in safe code all together and only use value and reference types.