April 09
On Tuesday, 9 April 2024 at 16:45:18 UTC, Walter Bright wrote:
> A concurrent collector fixes this problem. Rainer implemented one at one point, but there were some technical issues. It's worth revisiting.

Memory protection mechanisms are expensive and also cause pauses.

> Besides, the programmer can control when then the collection cycle is done.

What for?
April 09

On Tuesday, 9 April 2024 at 15:31:08 UTC, Lance Bachmeier wrote:

>

[snip]

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.

I don't doubt that there are some applications that will benefit from the types of GC algorithms that are enabled by write barriers, but I think the burden of proof is on the people proposing changes. They can create a fork with write barriers and benchmark some code vs. the normal compiler.

Regardless, if they can create a way to make it completely opt-in without breaking existing code, then that offsets much of the concern about performance.

April 10

On Tuesday, 9 April 2024 at 16:54:03 UTC, Walter Bright wrote:

>

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.

No, you misunderstood. There would be only one pointer type, whether it's write-gated would be controlled by a version switch.

What I meant is: if the write-gates are turned on, the write gate would check at runtime whether the memory pointed to by the new value is registered to the GC. If not, nothing is done apart from the assignment. Meaning, pointing to memory not controlled by the GC would still work, although the pointer writes would be slower than if write gates were not used.

There would be no difference in language semantics. Both GC-controlled memory and manually allocated memory work exactly the same in both cases. The difference would only be in performance.

April 11

On Tuesday, 9 April 2024 at 16:56:13 UTC, Walter Bright wrote:

>

That's what @nogc is for.

Mine detectors are helpful but it would be nice if there were less mines in my backyard.

April 12

On Thursday, 11 April 2024 at 07:09:00 UTC, Ogi wrote:

>

On Tuesday, 9 April 2024 at 16:56:13 UTC, Walter Bright wrote:

>

That's what @nogc is for.

Mine detectors are helpful but it would be nice if there were less mines in my backyard.

And there it is. This is where we always end up in the pro-GC vs. anti-GC debate. The anti-GC side eventually ends up with some version of "if only we could just get rid of the GC, then my life would finally be great."

The number of "mines" is not going to get smaller. It can't. It will probably only grow. D is a memory safe language, of which the GC is a cornerstone component, without the GC it is no longer a memory safe language. You have tools to avoid the GC, but even so, you're going to have to do more work to avoid it than if you don't. That's what you're signing up for when you go for manual memory management.

It really is that simple.

April 13

On Friday, 12 April 2024 at 22:13:53 UTC, Adam Wilson wrote:

>

D is a memory safe language, of which without the GC it is no longer a memory safe language.

That is not true. You can avoid heap allocation, or use allocation patterns with a safe interface like SafeRefCounted, or you can write programs that don't need deallocation, or you can avoid deallocating in @safe functions.

1 2 3 4 5 6 7 8 9 10 11
Next ›   Last »