www.digitalmars.com         C & C++   DMDScript  

digitalmars.D - The cost of write barriers

reply "Jonathan Barnard" <jonathan.t.barnard gmail.com> writes:
The upcoming version 1.4 of Go uses write barriers in preparation 
for the future implementation of a concurrent and generational 
GC. On the mailing list thread discussing the beta 
(https://groups.google.com/forum/#!topic/golang-nuts/7VAcfULjiB8), 
a few people note speed reductions of 30-50% in their benchmarks. 
I think this vindicates to a degree D's decision to avoid garbage 
collection strategies that require write barriers.
Nov 02 2014
next sibling parent reply "Araq" <rumpf_a web.de> writes:
On Sunday, 2 November 2014 at 08:48:46 UTC, Jonathan Barnard 
wrote:

 The upcoming version 1.4 of Go uses write barriers in 
 preparation for the future implementation of a concurrent and 
 generational GC. On the mailing list thread discussing the beta 
 (https://groups.google.com/forum/#!topic/golang-nuts/7VAcfULjiB8), 
 a few people note speed reductions of 30-50% in their 
 benchmarks. I think this vindicates to a degree D's decision to 
 avoid garbage collection strategies that require write barriers.


And I think these are meaningless results. You can see here for 
instance what a write barrier can look like:

http://psy-lob-saw.blogspot.de/2014/10/the-jvm-write-barrier-card-marking.html
Nov 02 2014
parent reply "Jonathan Barnard" <jonathan.t.barnard gmail.com> writes:
On Sunday, 2 November 2014 at 10:30:21 UTC, Araq wrote:

 And I think these are meaningless results. You can see here for 
 instance what a write barrier can look like:

 http://psy-lob-saw.blogspot.de/2014/10/the-jvm-write-barrier-card-marking.html


Would such an implementation also be possible in a language like 
Go or D with internal/'thin' pointers?
Nov 02 2014
next sibling parent "Araq" <rumpf_a web.de> writes:
 Would such an implementation also be possible in a language 
 like Go or D with internal/'thin' pointers?


Last time I thought about it, card marking is indeed the only 
write barrier that is not affected by interior pointers. I could 
be totally wrong though.
Nov 02 2014
prev sibling parent reply "thedeemon" <dlang thedeemon.com> writes:
On Sunday, 2 November 2014 at 10:36:13 UTC, Jonathan Barnard 
wrote:

 On Sunday, 2 November 2014 at 10:30:21 UTC, Araq wrote:

 And I think these are meaningless results. You can see here 
 for instance what a write barrier can look like:

 http://psy-lob-saw.blogspot.de/2014/10/the-jvm-write-barrier-card-marking.html




Btw, how are write barriers implemented in Go now?


 Would such an implementation also be possible in a language 
 like Go or D with internal/'thin' pointers?


Yes, however the compiler needs to know all the places where your 
code mutates pointers. That means you can't use memcpy to copy 
some data with pointers into an old object or array. And you 
can't mutate pointers from C code.
Nov 03 2014
next sibling parent "Paulo Pinto" <pjmlp progtools.org> writes:
On Monday, 3 November 2014 at 11:50:57 UTC, thedeemon wrote:

 On Sunday, 2 November 2014 at 10:36:13 UTC, Jonathan Barnard 
 wrote:

 On Sunday, 2 November 2014 at 10:30:21 UTC, Araq wrote:

 And I think these are meaningless results. You can see here 
 for instance what a write barrier can look like:

 http://psy-lob-saw.blogspot.de/2014/10/the-jvm-write-barrier-card-marking.html




 Btw, how are write barriers implemented in Go now?


Some information on the upcoming release notes.

http://tip.golang.org/doc/go1.4#impl


 Would such an implementation also be possible in a language 
 like Go or D with internal/'thin' pointers?


 Yes, however the compiler needs to know all the places where 
 your code mutates pointers. That means you can't use memcpy to 
 copy some data with pointers into an old object or array. And 
 you can't mutate pointers from C code.


Now it is officially forbidden to just give a Go pointer directly 
to a C function.

It needs to be given as an uintptr, if I am not mistaken.
Nov 03 2014
prev sibling parent "Jonathan Barnard" <jonathan.t.barnard gmail.com> writes:
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?
Nov 04 2014
prev sibling next sibling parent reply "Paulo Pinto" <pjmlp progtools.org> writes:
On Sunday, 2 November 2014 at 08:48:46 UTC, Jonathan Barnard 
wrote:

 The upcoming version 1.4 of Go uses write barriers in 
 preparation for the future implementation of a concurrent and 
 generational GC. On the mailing list thread discussing the beta 
 (https://groups.google.com/forum/#!topic/golang-nuts/7VAcfULjiB8), 
 a few people note speed reductions of 30-50% in their 
 benchmarks. I think this vindicates to a degree D's decision to 
 avoid garbage collection strategies that require write barriers.


Please also mention that those reductions are happening because 
the new code hasn't been optimized yet and Go 1.5 will get a 
concurrent generational GC.

--
Paulo
Nov 02 2014
parent "Paulo Pinto" <pjmlp progtools.org> writes:
On Sunday, 2 November 2014 at 13:13:17 UTC, Paulo Pinto wrote:

 On Sunday, 2 November 2014 at 08:48:46 UTC, Jonathan Barnard 
 wrote:

 The upcoming version 1.4 of Go uses write barriers in 
 preparation for the future implementation of a concurrent and 
 generational GC. On the mailing list thread discussing the 
 beta 
 (https://groups.google.com/forum/#!topic/golang-nuts/7VAcfULjiB8), 
 a few people note speed reductions of 30-50% in their 
 benchmarks. I think this vindicates to a degree D's decision 
 to avoid garbage collection strategies that require write 
 barriers.


 Please also mention that those reductions are happening because 
 the new code hasn't been optimized yet and Go 1.5 will get a 
 concurrent generational GC.

 --
 Paulo


Ooops, pressed send too soon. :(

I just wanted to mention the part that Go team is aware that the 
code still hasn't been fully optimized.

Sorry for the second part of the sentence. You did mentioned it.

--
Paulo
Nov 02 2014
prev sibling parent reply "deadalnix" <deadalnix gmail.com> writes:
On Sunday, 2 November 2014 at 08:48:46 UTC, Jonathan Barnard 
wrote:

 The upcoming version 1.4 of Go uses write barriers in 
 preparation for the future implementation of a concurrent and 
 generational GC. On the mailing list thread discussing the beta 
 (https://groups.google.com/forum/#!topic/golang-nuts/7VAcfULjiB8), 
 a few people note speed reductions of 30-50% in their 
 benchmarks. I think this vindicates to a degree D's decision to 
 avoid garbage collection strategies that require write barriers.


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.
Nov 03 2014
parent reply "thedeemon" <dlang thedeemon.com> writes:
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.


Required for what exactly? If you want generational GC, you'll 
need barriers everywhere, not only in shared heap.
Nov 04 2014
parent "deadalnix" <deadalnix gmail.com> writes:
On Tuesday, 4 November 2014 at 10:09:47 UTC, thedeemon wrote:

 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.


 Required for what exactly? If you want generational GC, you'll 
 need barriers everywhere, not only in shared heap.


Ok I see, I was think about write barrier for concurrent
collection. Sorry for the confusion.
Nov 04 2014