• piotrekg2 (5/5) Jul 30 2017 I would like to learn more about GC in D. For example can anyone
• rikki cattermole (8/15) Jul 30 2017 Basically instead of having possibly random data in the array, it forces...
• Marc =?UTF-8?B?U2Now7x0eg==?= (19/22) Jul 30 2017 The current GC is a conservative one, which means that it has at
• Moritz Maxeiner (14/17) Jul 30 2017 The primary locations to get information are the language

piotrekg2 <piotrekg2 gmail.com> writes:

I would like to learn more about GC in D. For example can anyone 
explain why do we need memset(0) here: 
https://github.com/dlang/phobos/blob/master/std/container/array.d#L356 ,
doesn't it assume a certain type of GC? What if there is a need to change the
GC algorithm in the future?

It would be great if you could point me out to articles on this 
subject.

rikki cattermole <rikki cattermole.co.nz> writes:

On 30/07/2017 10:12 AM, piotrekg2 wrote:
 I would like to learn more about GC in D. For example can anyone explain 
 why do we need memset(0) here: 
 https://github.com/dlang/phobos/blob/master/std/container/array.d#L356 , 
 doesn't it assume a certain type of GC? What if there is a need to 
 change the GC algorithm in the future?
 
 It would be great if you could point me out to articles on this subject.

Basically instead of having possibly random data in the array, it forces 
it to be all 0.

What its protecting against is false pointers and stopping the GC seeing 
a reference to a block of memory that doesn't exist.

It's just general protection against GC's thinking that memory is alive 
when it isn't. More of a problem for 32bit than 64bit. Hasn't got much 
to do with the algorithm :)

Marc =?UTF-8?B?U2Now7x0eg==?= <schuetzm gmx.net> writes:

On Sunday, 30 July 2017 at 09:12:53 UTC, piotrekg2 wrote:
 I would like to learn more about GC in D. For example can 
 anyone explain why do we need memset(0) here: 
 https://github.com/dlang/phobos/blob/master/std/container/array.d#L356 ,
doesn't it assume a certain type of GC? What if there is a need to change the
GC algorithm in the future?

The current GC is a conservative one, which means that it has at 
best an incomplete knowledge of the types in the memory it scans. 
Therefore, whenever it sees a value that, when interpreted as a 
pointer, points to a pool of memory owned by the GC, it needs to 
assume that it is indeed a pointer, which means it has to keep 
the referenced object alive.

A false pointer is one that only looks like a valid pointer but 
is in reality some other kind of data, or in this case data in a 
block of memory that's still allocated, but no longer actually in 
use. False pointers can keep GC-managed objects alive that could 
actually be freed, so they're something that should be avoided. 
The container overwrites the memory with zeroes because a zero 
value is never a valid pointer.

Changing the GC algorithm would do no harm here. The best we 
could hope for is that the GC at some pointer becomes fully 
precise (unlikely), so it can distinguish false from real 
pointers by itself. In this case, the memset would become 
unnecessary, but it wouldn't lead to wrong behaviour.

Moritz Maxeiner <moritz ucworks.org> writes:

On Sunday, 30 July 2017 at 09:12:53 UTC, piotrekg2 wrote:
 I would like to learn more about GC in D. [...]
 It would be great if you could point me out to articles on this 
 subject.

The primary locations to get information are the language 
specification [1] and the druntime documentation [2].
I also suggest reading the excellent GC series on the official 
language blog [3].
Additionally, in this [5] - despite being mostly about the Go GC 
- gives a good overview of garbage collection in general.



[1] https://dlang.org/spec/garbage.html
[2] https://dlang.org/phobos/core_memory.html
[3] https://dlang.org/blog/the-gc-series/
[4] 
http://www.infognition.com/blog/2014/the_real_problem_with_gc_in_d.html
[5] 
https://blog.plan99.net/modern-garbage-collection-911ef4f8bd8e?gi=78635e05a6ac#.6zz5an77a