low-latency GC

Bruce Carneal bcarneal at gmail.com
Sun Dec 6 08:36:49 UTC 2020


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.



More information about the Digitalmars-d-learn mailing list