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.

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 :)

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.

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