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