On 4/6/2024 9:04 AM, Carl Sturtivant wrote:
> Don't straw-man this: none of this says that you HAVE to use GC in D. There is no reason to oppose an ace GC for D on those grounds.

Consider the performance deficit from write-barriers.

On 09/04/2024 12:14 PM, Walter Bright wrote:
> On 4/6/2024 9:04 AM, Carl Sturtivant wrote:
>> Don't straw-man this: none of this says that you HAVE to use GC in D. There is no reason to oppose an ace GC for D on those grounds.
> 
> Consider the performance deficit from write-barriers.

D is in an excellent position to make write barriers opt-in, with different strategies allowing for different GC designs.

Its not an all or nothing situation that people seem to want it to be.

We can get the write barriers implemented and let some PhD students implement some more advanced GC designs.

No need to commit to any one strategy, people should be able to use what makes sense for their application!

On Tuesday, 9 April 2024 at 00:14:01 UTC, Walter Bright wrote:
> On 4/6/2024 9:04 AM, Carl Sturtivant wrote:
>> Don't straw-man this: none of this says that you HAVE to use GC in D. There is no reason to oppose an ace GC for D on those grounds.
>
> Consider the performance deficit from write-barriers.

Stopping the world is also a performance deficit, which accumulates all at one time.

On Tuesday, 9 April 2024 at 00:47:55 UTC, Richard (Rikki) Andrew Cattermole wrote:
> D is in an excellent position to make write barriers opt-in, with different strategies allowing for different GC designs.
>
> Its not an all or nothing situation that people seem to want it to be.
>
> We can get the write barriers implemented and let some PhD students implement some more advanced GC designs.

How would you add write barriers to D? Is it possible without extending the language?

On 09/04/2024 7:17 PM, Gregor Mückl wrote:
> On Tuesday, 9 April 2024 at 00:47:55 UTC, Richard (Rikki) Andrew Cattermole wrote:
>> D is in an excellent position to make write barriers opt-in, with different strategies allowing for different GC designs.
>>
>> Its not an all or nothing situation that people seem to want it to be.
>>
>> We can get the write barriers implemented and let some PhD students implement some more advanced GC designs.
> 
> How would you add write barriers to D? Is it possible without extending the language?

Its a glue code layer thing.

If you emit a write, guard it with a call into the GC (or if we have a known specific strategy that instead).

The language won't need to change, its all under the hood!

Other languages like Java change write barrier behavior a plenty. The bytecode however doesn't change when it does.

On 09/04/2024 11:04 PM, tchaloupka wrote:
> There is also no tool (that I know of) to help analyze memory leaks of the GC memory.
> Lately, I've spent almost a manweek trying to find the cause of the leak in a large codebase using vibe-d in a long-running service that just kept growing on memory. Not fun at all. While I could be using memory sanitizer tools with malloc managed memory just fine ;-)

Valgrind should work.

https://dlang.org/changelog/2.105.0.html#druntime.valgrind

On 10/04/2024 1:15 AM, Leonardo wrote:
> On Saturday, 6 April 2024 at 10:52:04 UTC, Ogi wrote:
>>> [...]
>>
>> This depends on the amount of latency. If it’s only “an extra millisecond” than yeah, not an issue. But if garbage collection can take more than entire game tick, than it’s a no-go.
>>
>> [...]
> 
> Based on this and my experiments, I think we should at least improve the GC, like Unity did with an incremental GC, to avoid spikes.
> https://docs.unity3d.com/Manual/performance-incremental-garbage-collection.html

Sing along with me: ~~ write barriers ~~

:)