The cost of write barriers

Jonathan Barnard via Digitalmars-d digitalmars-d at puremagic.com
Tue Nov 4 02:18:56 PST 2014


On Monday, 3 November 2014 at 11:50:57 UTC, thedeemon wrote:
> Btw, how are write barriers implemented in Go now?

It seems it's actually currently just a functional call[1], to 
simulate the performance cost of a write barrier. This is to 
smooth out the performance drop across multiple releases, rather 
than a single release bearing the full brunt of the write 
barrier's introduction.

1.https://code.google.com/p/go/source/browse/src/runtime/mgc0.go?name=default&r=f98b2e08a26867096c2dc78c5283097effcfa0ec#86

On Tuesday, 4 November 2014 at 06:09:21 UTC, deadalnix wrote:
> Write barrier are only required on objects that contain mutable 
> pointer and are shared. in D, that is a subset of the shared 
> heap. D's type system would allow to use such strategy while 
> mitigating the cost quite a lot.

Are there plans to take advantage of this? I've lost track of 
where the current GC effort is heading; is it focused on 
integrating the recent D2 port of that parallel collector, or on 
improving the current collector, or on pervasive reference 
counting?


More information about the Digitalmars-d mailing list