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.
