digitalmars.D.learn - need article: How is working D-GC?
- KnightMare (27/27) Jun 11 2019 please write some explanation about subj.
- =?UTF-8?B?UsOpbXkgTW91w6t6YQ==?= (15/42) Jun 11 2019 Mike Parker has written a series of articles explaining the D GC:
- rikki cattermole (5/7) Jun 11 2019 Its already in.
please write some explanation about subj. - what exactly it scans? - why it scan data-segment? https://issues.dlang.org/show_bug.cgi?id=15723 https://issues.dlang.org/show_bug.cgi?id=19947 precise GC doesn't help with issues. - maybe add new type like gcpointer or something (making word "pointer" as keyword is not good idea) that must be scanned 100%. some mix of uint/ulong and void* with arithmetic support +=N -=N for bytes offset without any cast. not for safe. - maybe to make precise gc as option for compiler (not runtime) that will scans only pointer vars, gcpointer and other roots, not the all data segment (no longs, no doubles[5], no long/double fields in structs etc)? at runtime GC has no info about data-segment so its pessimistic and scans all of it (probably. need clarifying article). if make it compile option than compiler/linker can say exactly what should be scanned and what shouldn't. - when I transfer some gcptr to C or another library its only my responsibility to invoke GC.addRoot/addRange or some .holdThisData in case addRoot/addRange has another mean. the point is "dont scan everything, scan what user/compiler point to u". GC is dangerous for now, it should be fixed, nobody will work with such GC at critical/24/7 systems. imo pessimistic gc should be removed at all. in case GC won't be fixed tell us, it will be fair.
Jun 11 2019
On Tuesday, 11 June 2019 at 18:20:59 UTC, KnightMare wrote:please write some explanation about subj. - what exactly it scans? - why it scan data-segment? https://issues.dlang.org/show_bug.cgi?id=15723 https://issues.dlang.org/show_bug.cgi?id=19947 precise GC doesn't help with issues. - maybe add new type like gcpointer or something (making word "pointer" as keyword is not good idea) that must be scanned 100%. some mix of uint/ulong and void* with arithmetic support +=N -=N for bytes offset without any cast. not for safe. - maybe to make precise gc as option for compiler (not runtime) that will scans only pointer vars, gcpointer and other roots, not the all data segment (no longs, no doubles[5], no long/double fields in structs etc)? at runtime GC has no info about data-segment so its pessimistic and scans all of it (probably. need clarifying article). if make it compile option than compiler/linker can say exactly what should be scanned and what shouldn't. - when I transfer some gcptr to C or another library its only my responsibility to invoke GC.addRoot/addRange or some .holdThisData in case addRoot/addRange has another mean. the point is "dont scan everything, scan what user/compiler point to u". GC is dangerous for now, it should be fixed, nobody will work with such GC at critical/24/7 systems. imo pessimistic gc should be removed at all. in case GC won't be fixed tell us, it will be fair.Mike Parker has written a series of articles explaining the D GC: https://dlang.org/blog/the-gc-series/ It talks about: - its basic operations, - how to measure its usage and profile a D program for allocations, - various strategies to manage memory like the stack and C's malloc/free functions. At D Conf 2019, Walter Bright made his keynote presentation about memory allocation strategies, going beyond the GC: - video: https://www.youtube.com/watch?v=_PB6Hdi4R7M - slides: https://dconf.org/2019/talks/bright.pdf If I recall correctly, there is (or was) also a precise GC in the work, but I currently don't have any links to it.
Jun 11 2019
On 12/06/2019 11:40 AM, Rémy Mouëza wrote:If I recall correctly, there is (or was) also a precise GC in the work, but I currently don't have any links to it.Its already in. Its a modification on the conservative GC to make it more efficient. https://github.com/dlang/druntime/blob/master/src/core/gc/config.d#L19 https://github.com/dlang/druntime/blob/master/src/gc/impl/conservative/gc.d#L116
Jun 11 2019