On 17/05/2021 8:32 PM, sighoya wrote:
> Just a question, is anything about the GC part of the language spec of D?
> Is it possible to introduce a task local GC to D in another compiler without to touch the D language?

It has nothing to do with the compiler.

You can implement it fully in your own code base if you want and select it at runtime.

https://github.com/dlang/druntime/blob/master/src/core/gc/registry.d
https://github.com/dlang/druntime/blob/master/src/core/gc/config.d#L53

On Monday, 17 May 2021 at 10:39:39 UTC, rikki cattermole wrote:
>
> On 17/05/2021 8:32 PM, sighoya wrote:
>> Just a question, is anything about the GC part of the language spec of D?
>> Is it possible to introduce a task local GC to D in another compiler without to touch the D language?
>
> It has nothing to do with the compiler.

The stack meta info, suspension points and some other details are compilerdependant.

On Monday, 17 May 2021 at 11:09:00 UTC, Ola Fosheim Grostad wrote:
> On Monday, 17 May 2021 at 10:39:39 UTC, rikki cattermole wrote:
>>
>> On 17/05/2021 8:32 PM, sighoya wrote:
>>> Just a question, is anything about the GC part of the language spec of D?
>>> Is it possible to introduce a task local GC to D in another compiler without to touch the D language?
>>
>> It has nothing to do with the compiler.
>
> The stack meta info, suspension points and some other details are compilerdependant.

That is, if one wants to avoid a clunky library version. Trying to be generic underutilizes the features of the backend. The goal should be best if breed, whch makes it backend specific.

On Monday, 17 May 2021 at 10:39:39 UTC, rikki cattermole wrote:
>
> It has nothing to do with the compiler.
>
> You can implement it fully in your own code base if you want and select it at runtime.
>
> https://github.com/dlang/druntime/blob/master/src/core/gc/registry.d
> https://github.com/dlang/druntime/blob/master/src/core/gc/config.d#L53

There have been a few tracing GC algorithms but still D is forced to used traced GC.

Unfortunately D ends up in the pit as usual, it is chess mate. Walter do not want to implement reference types/fat pointers types which makes RC impossible by standard. Moving druntime/phobos away from GC is also a too big of task which might also break something.

On Monday, 17 May 2021 at 16:47:36 UTC, IGotD- wrote:
> On Monday, 17 May 2021 at 10:39:39 UTC, rikki cattermole wrote:
>>
>> It has nothing to do with the compiler.
>>
>> You can implement it fully in your own code base if you want and select it at runtime.
>>
>> https://github.com/dlang/druntime/blob/master/src/core/gc/registry.d
>> https://github.com/dlang/druntime/blob/master/src/core/gc/config.d#L53
>
> There have been a few tracing GC algorithms but still D is forced to used traced GC.

Yes, the GC runtime interface is not good enough, task based should be stackless at suspension points, but use system stack for suspension-free functions. That way you can have a massive amount of suspended tasks. Another feature that is needed is merging GC heaps, so that you can join tasks that has been split to maximise parallelism. Etc.

> Unfortunately D ends up in the pit as usual, it is chess mate. Walter do not want to implement reference types/fat pointers types which makes RC impossible by standard.

Not impossible, you can do like C++, use smart pointers, but unlike C++ inject a new IR before LLVM IR that does ARC. Also, let the smart pointers use compiler intrinsics for ARC.