Garbage Collection for Systems Programmers

[Dukc]

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):

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

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

```D
*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

```D
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.