Permalink
Reply
On Saturday, 17 December 2022 at 18:44:21 UTC, IGotD- wrote:
>I see concurrent GC (or at least something that doesn't stop other threads) as the only choice. The more I look into the D garbage collector the more surprised I become.
I wouldn't say it is is the only choice. If D was willing to make a bold move towards modelling software as short lived actors/tasks then you could use arenas that typically don't collect, but is wiped out when the task is done (collection only happens if you run out of memory).
Right now I am personally more interested in Carbon that will be 100% GC free. I like that they take a stance on memory management overhead. There are also interesting things going on in the research field with separation logic and similar formalizations, still probably 20 years until it will be generally useful, but things are moving IMO. There is also some interest in memory pools/arenas in the C++ community I think, and there seems to be an interest in Apple for integrating C++ and Swift, so maybe pairing one managed and one unmanaged language is the way forward, short term. So overall, the global picture is nuanced.
>- Scan the stack from the stack pointer and upwards.
- Scan all the registers, making the algorithm non portable.
- Scan all the globally allocated memory
- Scan all the thread local storage. This usually live on the stack for the libraries that are loaded at startup. This information must be read out before or after the thread starts.
- The threads that were interrupted, the context must be read out including the position of the stack pointer.
Application specific collectors don't have to do all this work as they will only collect at specific points where the state is known and where the number of live objects are minimal. This is something one should be able to use verification technologies for, basically proving that there are no stray references hanging around when you start collecting. Rust is only the beginning I think.
>- You need metadata for the tracing graph. D uses typeinfo in order to reduce the scanning of objects, this is nice but at the same increases the complexity.
You could probably generate a hardcoded "optimal" scanner statically at linktime after LTO, but that only makes it somewhat faster, and not really better.
>making this possible. It's not completely straight forward and suspending all threads require quite different approaches on each system. What if they didn't?
Suspending all threads, for whatever reason, is a terrible idea. Just think about Amdahl's law:
https://en.wikipedia.org/wiki/Amdahl%27s_law#/media/File:AmdahlsLaw.svg
>So the question if GC is built into the standard library is positive or negative, then my answer is that in the case of the D it certainly increase the complexity quite a lot. What if there was a simpler path?
ARC.
