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