On Friday, 6 November 2020 at 04:48:42 UTC, Manu wrote:

> It sounds like you have used VisualD incorrectly.
> It sounds to me like you did not use the D/VC++ project template, which is
> msbuild native, and works extremely well. Maybe you used the old project
> format from 5 years ago... I think that's still in there, but you shouldn't
> use it today.
> Look for the D/VC++ project wizard, and try your evaluation again.

Yes, the integration is better with the D/VC++ template and passing arguments work. However, dmdserver.exe is still crashing by my code for example and default build action leads to link errors while the outside "Compile and Debug" command from the plugin menu works as expected.

On Friday, 6 November 2020 at 23:16:53 UTC, IGotD- wrote:
>
> D should take the same route as Nim. Nim has several garbage collection algorithms and can swap them out as they see fit. Latest reference counting algorithm has been a success for Nim and the language just keep on improving because they have invested in good GC as well an architecture where they can continue to play with different approaches.
>
> GC is not bad but the language must support changing GC algorithms.

D already supports changing GC algorithms. [1] Currently, there are only two algorithms to choose from (conservative and precise), but there's nothing stopping anyone from adding more.

[1] https://dlang.org/spec/garbage.html#gc_config

On Sunday, 8 November 2020 at 01:22:15 UTC, Paul Backus wrote:
>
> D already supports changing GC algorithms. [1] Currently, there are only two algorithms to choose from (conservative and precise), but there's nothing stopping anyone from adding more.
>
> [1] https://dlang.org/spec/garbage.html#gc_config

D only supports tracing GC.

On Sunday, 8 November 2020 at 01:36:09 UTC, IGotD- wrote:
> On Sunday, 8 November 2020 at 01:22:15 UTC, Paul Backus wrote:
>>
>> D already supports changing GC algorithms. [1] Currently, there are only two algorithms to choose from (conservative and precise), but there's nothing stopping anyone from adding more.
>>
>> [1] https://dlang.org/spec/garbage.html#gc_config
>
> D only supports tracing GC.

So?

There are plenty tracing GC algorithms to choose from:

- mark and sweep
- concurrent
- fully parallel
- pauseless
- colouring
- with nursery
- with several generations
- thread local
- real time
- soft real time
- how far interior pointers are supported
- with or without safe points
- copy on write for mutations

http://gchandbook.org/contents.html provides a good overview, although it has been somehow superseded by research published in ACM SIGPLAN and IEEE papers as well.

Plenty of opportunities for alternative implementations to plug into D's runtime.

On Sunday, 8 November 2020 at 01:22:15 UTC, Paul Backus wrote:
> On Friday, 6 November 2020 at 23:16:53 UTC, IGotD- wrote:
>>
>> D should take the same route as Nim. Nim has several garbage collection algorithms and can swap them out as they see fit. Latest reference counting algorithm has been a success for Nim and the language just keep on improving because they have invested in good GC as well an architecture where they can continue to play with different approaches.
>>
>> GC is not bad but the language must support changing GC algorithms.
>
> D already supports changing GC algorithms. [1] Currently, there are only two algorithms to choose from (conservative and precise), but there's nothing stopping anyone from adding more.

Language semantics stops it. D cannot do precise GC with the current semantics, you need to locate all actual pointers, including those in unions. The default is essentially a boehm collector and the other one is semi-conservative, not precise...

On Sunday, 8 November 2020 at 09:28:05 UTC, Ola Fosheim Grøstad wrote:
> Language semantics stops it. D cannot do precise GC with the current semantics, you need to locate all actual pointers, including those in unions. The default is essentially a boehm collector and the other one is semi-conservative, not precise...

If I understand it right you also can't have a GC with heap compaction in D, because this would invalidate pointers. Most high performance GCs use heap compaction...

The language relies on GC (you can't use all features without it), but at the same time it is designed in a way you can't have a competitive GC (compared to JVM/CLR).

On Sunday, 8 November 2020 at 13:28:02 UTC, random wrote:
> If I understand it right you also can't have a GC with heap compaction in D, because this would invalidate pointers. Most high performance GCs use heap compaction...

It is possible, but expensive..

> The language relies on GC (you can't use all features without it), but at the same time it is designed in a way you can't have a competitive GC (compared to JVM/CLR).

The problem is that raw C pointers can be owning pointers. So it would be a breaking change.

On Sunday, 8 November 2020 at 13:39:17 UTC, Ola Fosheim Grøstad wrote:
>
> The problem is that raw C pointers can be owning pointers. So it would be a breaking change.

We need to break this change because if we don't D will not progress. The alternative is some pointer container as if we would litter C++ std::shared_ptr all over the place, not too happy about that though. This will of course be a library change but I think we should have a language classifier for it. This doesn't really need to be a breaking change but an additional "fat pointer".

On Sunday, 8 November 2020 at 09:27:08 UTC, Paulo Pinto wrote:
> On Sunday, 8 November 2020 at 01:36:09 UTC, IGotD- wrote:
>> On Sunday, 8 November 2020 at 01:22:15 UTC, Paul Backus wrote:
>>>
>>> D already supports changing GC algorithms. [1] Currently, there are only two algorithms to choose from (conservative and precise), but there's nothing stopping anyone from adding more.
>>>
>>> [1] https://dlang.org/spec/garbage.html#gc_config
>>
>> D only supports tracing GC.
>
> So?
>
> There are plenty tracing GC algorithms to choose from:
>
> - mark and sweep
> - concurrent
> - fully parallel
> - pauseless
> - colouring
> - with nursery
> - with several generations
> - thread local
> - real time
> - soft real time
> - how far interior pointers are supported
> - with or without safe points
> - copy on write for mutations
>
> http://gchandbook.org/contents.html provides a good overview, although it has been somehow superseded by research published in ACM SIGPLAN and IEEE papers as well.
>
> Plenty of opportunities for alternative implementations to plug into D's runtime.

Would it be possible to tune the existing GC to control how much garbage is collected? I mean, for instance, to tell the GC to label objects as garbage as normal, but only to collect so much at a time. The others would be saved to be collected later.

On Sunday, 8 November 2020 at 14:21:25 UTC, jmh530 wrote:
> Would it be possible to tune the existing GC to control how much garbage is collected? I mean, for instance, to tell the GC to label objects as garbage as normal, but only to collect so much at a time. The others would be saved to be collected later.

Drop destructors and then you dont have to do much explicit collection.

But the tracing is still expensive. You can try to do separation at the type level and use ideas from generational, but it will only work sometimes and you need global analysis.

Thread local collection + global refcounting is a better fit for D.

Or just ARC, which I would prefer if done with global static analysis.