On Sunday, 7 April 2024 at 09:44:21 UTC, ryuukk_ wrote:
> On Saturday, 6 April 2024 at 19:09:12 UTC, Sebastian Nibisz wrote:
>> Write barrier can be as cheap as a single atomic write.
>
> Again, asking to become even worse than Java

This is better than Java.

> Java's latest new concurrent GC doesn't need write barriers

That's not true.

You either use a write barrier or you stop the world; otherwise, it is impossible. All Java GCs use write barriers and pause threads. The GC for D can be completely pauseless.

On Sunday, 7 April 2024 at 09:44:21 UTC, ryuukk_ wrote:
> On Saturday, 6 April 2024 at 19:09:12 UTC, Sebastian Nibisz wrote:
>> On Saturday, 6 April 2024 at 16:49:44 UTC, Richard (Rikki) Andrew Cattermole wrote:
>>> Modern GC's tend to need write barriers to make them work.
>>
>> Write barrier can be as cheap as a single atomic write.
>
> Again, asking to become even worse than Java
>
> Java's latest new concurrent GC doesn't need write barriers
>
> Rust is the best evidence that nobody wants a system language with a GC, only Microsoft do, and they has lost

Swift is a systems language with a GC, and before you mention RC isn't, I suggest reading proper CS material on automatic memory management research, and not random blog posts on the matter.

On Sunday, 7 April 2024 at 09:44:21 UTC, ryuukk_ wrote:
> Rust is the best evidence that nobody wants a system language with a GC, only Microsoft do, and they has lost

Please, remember that D is not some low level system programming language only. Most people would be happy to not fight with memory management, and especially companies that want to minimize development costs, with no expense at application security.

Best regards,
Alexandru.

On Sunday, 7 April 2024 at 10:28:37 UTC, Paulo Pinto wrote:
> On Sunday, 7 April 2024 at 09:44:21 UTC, ryuukk_ wrote:
>> On Saturday, 6 April 2024 at 19:09:12 UTC, Sebastian Nibisz wrote:
>>> On Saturday, 6 April 2024 at 16:49:44 UTC, Richard (Rikki) Andrew Cattermole wrote:
>>>> Modern GC's tend to need write barriers to make them work.
>>>
>>> Write barrier can be as cheap as a single atomic write.
>>
>> Again, asking to become even worse than Java
>>
>> Java's latest new concurrent GC doesn't need write barriers
>>
>> Rust is the best evidence that nobody wants a system language with a GC, only Microsoft do, and they has lost
>
> Swift is a systems language with a GC, and before you mention RC isn't, I suggest reading proper CS material on automatic memory management research, and not random blog posts on the matter.

Smarter than what people suggest on this forum

On Sunday, 7 April 2024 at 10:04:37 UTC, Sebastian Nibisz wrote:
>> Java's latest new concurrent GC doesn't need write barriers
>
> That's not true.
>
> You either use a write barrier or you stop the world; otherwise, it is impossible. All Java GCs use write barriers and pause threads. The GC for D can be completely pauseless.

You can also have read barriers, but the typical program does vastly more read than writes, so this is a losing strategy.

On 3/31/2024 7:22 AM, Adam wrote:
> Thought (this)[1] was an interesting read, and is a good counterpoint to all those who refuse to give D a change because of GC.
> 
> [1]: https://bitbashing.io/gc-for-systems-programmers.html

On HN:

https://news.ycombinator.com/item?id=39873692

On 4/1/2024 1:45 PM, Adam Wilson wrote:
> Personally, I blame the OS/Game crowd for single-handedly keeping D out of the web service space for the past *decade* because, instead of improving the GC to the point that long-running processes are possible, we've built a mountain of (mis)features designed to assuage their demands. I maintain that this was probably the second biggest mistake in D's history.

The sad thing is if you don't want the GC in your program, don't use 'new'. I can never get this point across.

> We need to accept a fact that I learned at DConf 2017, the no-GC crowd will not be silenced until the GC is removed from the language. However, Walter has said the GC is here to stay. Therefore, the no-GC crowd will never be silenced. We've given them a plethora of tools to work without the GC. It is time that we stopped giving them so much our time. We have bigger problems to solve.

One unexpected yuge advantage to having the GC in D is it enables CTFE.

On 3/31/2024 8:52 AM, Anonymouse wrote:
> We don't have a moving, recompacting, generational GC though. This doesn't invalidate the points he makes, but it's not quite apples vs apples.

D doesn't have a moving collector because if there is a pointer into a GC allocated object, and the object is moved, then the pointer is pointing to garbage. There goes memory safety out the window.

It is possible to detect those pointers and "pin" that particular allocation so it doesn't move, and I wrote such a collector long ago. It's called a partially compacting collector. (I thought I had invented this, but then later found a paper on it.)

This could be done for D, it isn't that hard.

As for a generational collector, this relies on the collector being notified when an allocated object gets mutated. This requires adding a "write gate" to the generated code. All writes through pointers execute additional code to notify the collector that the object changed.

This is fine if all memory is allocated via the collector. But in a mixed allocator environment, you're looking at a severe performance cost. So D doesn't do that.

At one point I did implement a scheme whereby the the GC's pages were marked "read only", and so when a write was done, the CPU would seg fault. A handler was made for the seg fault which notified the GC that it changed, and made the page writeable again. This involved no extra code for writes.

Unfortunately, benchmarking showed that it was way too slow to be viable. Oh well.

On 4/2/2024 8:31 AM, H. S. Teoh wrote:
> Yes, undocumented compiler hooks are a big barrier to adaptability. This
> needs to be refactored.  Right now there are tons of undocumented
> conventions and hooks that you basically have to do trial-and-error to
> discover.  This needs to be documented and refactored to a proper API
> instead.
> 
> Yeah while getting my D code to run in wasm, I discovered that there's a
> lot of stuff in object.d that actually only matters to druntime backend
> code. Would be nice to get rid of this stuff.

Please document these in a bugzilla issue. Thanks!