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