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.

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.

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