www.digitalmars.com         C & C++   DMDScript  

digitalmars.D.learn - GC

reply 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.
Jul 30
next sibling parent 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 :)
Jul 30
prev sibling next sibling parent 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.
Jul 30
prev sibling parent 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
Jul 30