low-latency GC
Ola Fosheim Grostad
ola.fosheim.grostad at gmail.com
Sun Dec 6 08:12:58 UTC 2020
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.
> 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.
> 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.
> 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.
More information about the Digitalmars-d-learn
mailing list