On Sunday, 6 December 2020 at 08:12:58 UTC, Ola Fosheim Grostad
wrote:
On Sunday, 6 December 2020 at 07:45:17 UTC, Bruce Carneal wrote:
GCs scan memory, sure. Lots of variations. Not germane. Not
a rationale.
We need to freeze the threads when collecting stacks/globals.
OK. Low latency GCs exist.
D is employed at multiple "levels". Whatever level you call
it, Go and modern JVMs employ low latency GCs in
multi-threaded environments. Some people would like to use D
at that "level".
Yes, but they don't allow low level programming. Go also freeze
to sync threads this has a rather profound impact on code
generation. They have spent a lot of effort on sync
instructions in code gen to lower the latency AFAIK.
So, much of the difficulty in bringing low-latency GC to dlang
would be the large code gen changes required. If it is a really
big effort then that is all we need to know. Not worth it until
we can see a big payoff and have more resources.
My question remains: how difficult would it be to bring such
technology to D as a GC option? Is it precluded somehow by
the language? Is it doable but quite a lot of effort because
...?
Is it no big deal once you have the GC itself because you
only need xyz hooks? Is it ...?
Get rid of the system stack and globals. Use only closures and
put in a restrictive memory model. Then maybe you can get a
fully no freeze multi threaded GC. That would be a different
language.
It would be, but I don't think it is the only way to get lower
latency GC. That said, if the code gen effort you mentioned
earlier is a big deal, then no need to speculate/examine further.
Also, I think Walter may have been concerned about read
barrier overhead but, again, I'm looking for feasibility
information. What would it take to get something that we
could compare?
Just add ARC + single threaded GC. And even that is quite
expensive.
Thanks for the feedback.
