How difficult would it be to add a, selectable, low-latency GC to dlang?

Is it closer to "we cant get there from here" or "no big deal if you already have the low-latency GC in hand"?

I've heard Walter mention performance issues (write barriers IIRC).  I'm also interested in the GC-flavor performance trade offs but here I'm just asking about feasibility.

On Sunday, 6 December 2020 at 05:16:26 UTC, Bruce Carneal wrote:
> How difficult would it be to add a, selectable, low-latency GC to dlang?
>
> Is it closer to "we cant get there from here" or "no big deal if you already have the low-latency GC in hand"?
>
> I've heard Walter mention performance issues (write barriers IIRC).  I'm also interested in the GC-flavor performance trade offs but here I'm just asking about feasibility.

The only reasonable option for D is single threaded GC or ARC.

On Sunday, 6 December 2020 at 05:29:37 UTC, Ola Fosheim Grostad wrote:
> On Sunday, 6 December 2020 at 05:16:26 UTC, Bruce Carneal wrote:
>> How difficult would it be to add a, selectable, low-latency GC to dlang?
>>
>> Is it closer to "we cant get there from here" or "no big deal if you already have the low-latency GC in hand"?
>>
>> I've heard Walter mention performance issues (write barriers IIRC).  I'm also interested in the GC-flavor performance trade offs but here I'm just asking about feasibility.
>
> The only reasonable option for D is single threaded GC or ARC.

OK.  Some rationale?  Do you, for example, believe that no-probable-dlanger could benefit from a low-latency GC?  That it is too hard to implement?  That the language is somehow incompatible? That ...

On Sunday, 6 December 2020 at 05:41:05 UTC, Bruce Carneal wrote:
> OK.  Some rationale?  Do you, for example, believe that no-probable-dlanger could benefit from a low-latency GC?  That it is too hard to implement?  That the language is somehow incompatible? That ...

The GC needs to scan all the affected call stacks before it can do incremental collection. Multi threaded GC is generally not compatible with low level programming.

On Sunday, 6 December 2020 at 06:52:41 UTC, Ola Fosheim Grostad wrote:
> On Sunday, 6 December 2020 at 05:41:05 UTC, Bruce Carneal wrote:
>> OK.  Some rationale?  Do you, for example, believe that no-probable-dlanger could benefit from a low-latency GC?  That it is too hard to implement?  That the language is somehow incompatible? That ...
>
> The GC needs to scan all the affected call stacks before it can do incremental collection. Multi threaded GC is generally not compatible with low level programming.

GCs scan memory, sure.  Lots of variations.  Not germane.  Not a rationale.

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".

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 ...?

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?

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.

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.

On Sunday, 6 December 2020 at 08:36:49 UTC, Bruce Carneal wrote:
>> 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.

Well, you could in theory avoid putting owning pointers on the stack/globals or require that they are registered as gc roots. Then you don't have to scan the stack. All you need then is write barriers. IIRC

On Sunday, 6 December 2020 at 08:59:49 UTC, Ola Fosheim Grostad wrote:
> Well, you could in theory avoid putting owning pointers on the stack/globals or require that they are registered as gc roots. Then you don't have to scan the stack. All you need then is write barriers. IIRC

Abd read barriers... I assume. However with single threaded incremental, write barriers should be enough.

On Sunday, 6 December 2020 at 05:29:37 UTC, Ola Fosheim Grostad wrote:
> On Sunday, 6 December 2020 at 05:16:26 UTC, Bruce Carneal wrote:
>> How difficult would it be to add a, selectable, low-latency GC to dlang?
>>
>> Is it closer to "we cant get there from here" or "no big deal if you already have the low-latency GC in hand"?
>>
>> I've heard Walter mention performance issues (write barriers IIRC).  I'm also interested in the GC-flavor performance trade offs but here I'm just asking about feasibility.
>
> The only reasonable option for D is single threaded GC or ARC.

It has to be either some kind of heavily customisable small GC (i.e. with our resources the GC cannot please everyone), or arc. The GC as it is just hurts the language.

Realistically, we probably need some kind of working group or at least serious discussion to really narrow down where to go in the future. The GC as it is now must go, we need borrowing to work with more than just pointers, etc.

The issue is that it can't just be done incrementally, it needs to be specified beforehand.