April 09

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.

Assignments to a pointer probably should call DRuntime handle. As code example, any time one assigns to a pointer (including dynamic arrays, class references, delegate contexts and so on):

int* ptr;
ptr = new int(35);

...it would be treated as (without doing the safety checks):

*cast(size_t*) &ptr = __ptrWrite!int(cast(size_t) ptr, cast(size_t) new int(35))

The DRuntime definition for present behaviour would be simply

pragma(inline, true)
size_t __ptrAssign(Pointee)(size_t oldVal, size_t newVal)
 => newVal;

and this would remain an option, but alternatively __ptrWrite can have a write gate. If the write gate would just ignore any pointers not registered to the GC it would probably continue to work with existing code with no changes other than a slight slowdown.

This would enable a tri-color GC, and it's better performance could easily win far more than the write gate overhead costs in most cases. The existing mark-and-sweep collector can still remain an option for those who don't want write gates.

Also even when the write gates are used you could still forgo them explicitly in unsafe code to by writing *cast(size_t*) &ptr = cast(size_t) newValue. Or probably use a less ugly library function to do the same.

April 09
On Wed, Apr 10, 2024 at 01:19:22AM +1200, Richard (Rikki) Andrew Cattermole via Digitalmars-d wrote:
> 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 ~~
> 
> :)

Write barriers!  We've been singing this tune for literally years. It's about time we actually did it instead of merely talking about it!


T

-- 
Too many people have open minds but closed eyes.
April 09

On Tuesday, 9 April 2024 at 14:14:08 UTC, H. S. Teoh wrote:

>

[snip]

>

Sing along with me: ~~ write barriers ~~

:)

Write barriers! We've been singing this tune for literally years. It's about time we actually did it instead of merely talking about it!

T

If something hasn't happened for years, usually there are good reasons why. Walter raised some recently here [1].

If you force everything to go through the GC, then you avoid some complexity, but you have the added cost of write barriers all the time.

If you're in a mixed memory environment, you end up needing two types of pointers (one managed, one unmanaged) and that leads to a lot of complications that people tend to not want to deal with.

[1] https://forum.dlang.org/post/uv1l7p$2tu2$1@digitalmars.com

April 09

On Tuesday, 9 April 2024 at 15:02:52 UTC, jmh530 wrote:

>

On Tuesday, 9 April 2024 at 14:14:08 UTC, H. S. Teoh wrote:

>

[snip]

>

Sing along with me: ~~ write barriers ~~

:)

Write barriers! We've been singing this tune for literally years. It's about time we actually did it instead of merely talking about it!

T

If something hasn't happened for years, usually there are good reasons why. Walter raised some recently here [1].

If you force everything to go through the GC, then you avoid some complexity, but you have the added cost of write barriers all the time.

If you're in a mixed memory environment, you end up needing two types of pointers (one managed, one unmanaged) and that leads to a lot of complications that people tend to not want to deal with.

[1] https://forum.dlang.org/post/uv1l7p$2tu2$1@digitalmars.com

I honestly don’t find that line of argument very convincing. There are no numbers backing up the conclusions, and not even a specific application given. We already have experience with the status quo and the problems it can cause. There’s no justification for ruling out other options based on speculation that the performance hit will be unacceptable.

April 09

On Tuesday, 9 April 2024 at 13:50:34 UTC, Dukc wrote:

>

On Tuesday, 9 April 2024 at 00:14:01 UTC, Walter Bright wrote:

>

Consider the performance deficit from write-barriers.

Assignments to a pointer probably should call DRuntime handle.
...

Thanks, I've filed a bugzilla enhancement that links to your post:
https://issues.dlang.org/show_bug.cgi?id=24492

It also links to a discussion where Walter appears to be OK with opt-in write barriers.

April 09
On 4/8/2024 5:47 PM, Richard (Rikki) Andrew Cattermole wrote:
>> 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.

It would be a massive bifurcation of the language. It affects everything. Languages that use this tend to have a lot of low-level C systems code, because those languages are not systems implementation languages. Trying to mix code that does and does not do write gates will be very tedious and error prone in hard-to-detect ways.

The net advantage tilts towards write barriers when the language does pretty much all its allocation with the GC. D is not like that.

Rust is a contender, does not use GC, and does not use write barriers. I know that D's @live has elicited minimal interest, but it does provide an opportunity to say that D is a memory safe language.

April 09
On 4/8/2024 5:51 PM, Sebastian Nibisz wrote:
> Stopping the world is also a performance deficit, which accumulates all at one time.


A concurrent collector fixes this problem. Rainer implemented one at one point, but there were some technical issues. It's worth revisiting.

Besides, the programmer can control when then the collection cycle is done.
April 09
On 4/9/2024 6:50 AM, Dukc wrote:
> If the write gate would just ignore any pointers not registered to the GC it would probably continue to work with existing code with no changes other than a slight slowdown.

This appears to require that the language would be cognizant of two different pointer types - gc pointers, and non-gc pointers. This concept was implemented in Microsoft's "Managed C++" language.

It's still in use, but I never hear anyone mention it. The two-pointer-type scheme is a massive increase in complexity that the programmer has to deal with. For example,

    int strcmp(char* s1, char* s2);

now requires 4 declarations (& means a GC pointer):

    int strcmp(char* s1, char* s2);
    int strcmp(char& s1, char* s2);
    int strcmp(char* s1, char& s2);
    int strcmp(char& s1, char& s2);

People dealt with multiple pointer types in the DOS 16 bit days, and I was very glad to be able to get away from that.
April 09
That's what @nogc is for.
April 10
On 10/04/2024 4:41 AM, Walter Bright wrote:
> On 4/8/2024 5:47 PM, Richard (Rikki) Andrew Cattermole wrote:
>>> 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.
> 
> It would be a massive bifurcation of the language. It affects everything. Languages that use this tend to have a lot of low-level C systems code, because those languages are not systems implementation languages. Trying to mix code that does and does not do write gates will be very tedious and error prone in hard-to-detect ways.

Yes it could do that.

We would need to set a flag for this in ModuleInfo to detect when a binary isn't compiled with write barriers. Given a specific strategy.

But even then it's only going to be a partial solution.

You can only turn on write barriers if you know your program can make use of them safely.

I am in no way suggesting we make this opt-out.

Making this opt-in gives us a ton of room for some PhD students to research, write papers ext. and hopefully come up with something that'll keep people happy that could benefit some extra work on their part.

It's good to remember that just because write barriers are codegen'd in, they may be no-op if the GC is StW. So it isn't end of the world. Depends upon the write barrier strategy.