On Wednesday, 20 July 2022 at 09:35:14 UTC, Templated Person wrote:
>On Wednesday, 20 July 2022 at 07:23:04 UTC, Nicholas Wilson wrote:
>We have multiple GC's
Do we really have multiple GCs though? How do you we use them, what are the advantages / disadvantages of each one?
Yes, there is the standard (conservative) GC, there is a Precise GC (which is really the same as the standard GC but with a precise sweep), and there is a fork GC (which is only for linux) which is different to the other two.
I believe you can choose which one with a --DRT
flag, and I think you can set some config at runtime in druntime somewhere, but I'm not sure. I've not bothered to change it.
The standard GC is a stop the world, conservative mark and sweep. It treats any value that looks like it could point to valid objects to be pointers (called false pointers). False pointers are only really a problem on 32-bit, which unless you are writing for microcontrollers are going the way of the dodo.
The precise GC is a stop the world, precise mark and sweep. Advantage: should not ever get confused by false pointers. Disadvantage often slower than the conservative GC.
Fork GC forks the current process and uses linux's cheap copy on write pages to mark dead objects asynchronously and then reap them. Advantages: not stop the world, asynchronous, usable in soft (and probably hard) realtime. Disadvantages: Linux only.
there is also std.experimental.allocator
Which is useless until Phobos data types are refactored to use that as a parameter.
Theres not really that many "data" types in the standard library. We should have a better container library that should be parameterised by the allocator that backs it, but the advantages of ranges is most of the code doing computation doesn't care what the memory is that backs it.
>If you ask me, D is better than most languages out there and it should be the default way of migrating out of C++. But that's not gonna happen until at least multiple of the following happens:
- The runtime gets leaner and more configurable, gotta have that wasm support.
LDC has (some?) support for WASM, and the runtime is becoming less reliant on TypeInfo, by becoming templated to what is actually used. I'm not sure how far away we are from a no typeinfo runtime being usable.
>- Modern features such as sum types & pattern matching, nullables & tuples in the language (not as libraries).
Good tuples would be very nice to have.
>- Allocators passed into functions (+ a "garbage collecting allocator" like we have now)
There is nothing stopping you from doing that now. I'm not sure what you mean here.