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?
May 17, 2021 Re: Plan for D | ||||
---|---|---|---|---|
| ||||
Posted in reply to Ola Fosheim Grostad |
May 17, 2021 Re: Plan for D | ||||
---|---|---|---|---|
| ||||
Posted in reply to sighoya | On Monday, 17 May 2021 at 08:32:16 UTC, sighoya wrote: >Just a question, is anything about the GC part of the language spec of D? I think so. At least if we drop memory safety. |
May 17, 2021 Re: Plan for D | ||||
---|---|---|---|---|
| ||||
Posted in reply to Ola Fosheim Grostad | On Monday, 17 May 2021 at 09:02:52 UTC, Ola Fosheim Grostad wrote: >On Monday, 17 May 2021 at 08:32:16 UTC, sighoya wrote: >Just a question, is anything about the GC part of the language spec of D? I think so. At least if we drop memory safety. Maybe not that even, but the meaning of shared is the issue, I think. Shared ought to refer to between tasks and not threads.... |
May 17, 2021 Re: Plan for D | ||||
---|---|---|---|---|
| ||||
Posted in reply to sighoya | 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 |
May 17, 2021 Re: Plan for D | ||||
---|---|---|---|---|
| ||||
Posted in reply to rikki cattermole | 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.
|
May 17, 2021 Re: Plan for D | ||||
---|---|---|---|---|
| ||||
Posted in reply to Ola Fosheim Grostad | 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.
|
May 17, 2021 Re: Plan for D | ||||
---|---|---|---|---|
| ||||
Posted in reply to dogman | On Sunday, 16 May 2021 at 21:42:32 UTC, dogman wrote: >On Sunday, 16 May 2021 at 21:38:51 UTC, dogman wrote: >[...] To the community, sorry am not trying to a$$hole. I just want this language and community to grow and flourish. I wish Andrei, Walter come up with Q&A to do a postmortem of the issues they faced and what we can do for it. I wish to help on small tasks whatever I can. I used to do lot of c++ and python and thought of a language somewhat like D. Then I saw D and always wished, if I could write in D daily. D on android, D on linux kernel/EBPF, D with WASM. Men too, I also want more D on embedded |
May 17, 2021 Re: Plan for D | ||||
---|---|---|---|---|
| ||||
Posted in reply to rikki cattermole | 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.
|
May 17, 2021 Re: Plan for D | ||||
---|---|---|---|---|
| ||||
Posted in reply to IGotD- | 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. |
May 17, 2021 Re: Plan for D | ||||
---|---|---|---|---|
| ||||
Posted in reply to dogman | On Thursday, 13 May 2021 at 20:57:13 UTC, dogman wrote: >Question to the core team. Whats the plan and roadmap for D ? It's already being used in industry. The plan is definitely that. >b. When are we planning to focus on memory safety and use that as our strength Now. This is the current priority. >c. Will we ever make D as both a GC and non GC language. It already is. The goal is to make non-GC use easier/safer without sacrificing the existing language and the ease-of-use of the GC. >d. Why there are no working groups for tooling, webframeworks, performance, compiler etc so that we can improve on each area. Because the foundation only has so much donation money. >f. D has all properties to make it a good language. But needs more work and marketing. Why cant we make D as a safe and fast extension to C++ & python My personal opinion is that it already is a safe and fast alternative to both those languages. What do you think is lacking? |