On Sunday, 8 May 2022 at 23:44:42 UTC, Ali Çehreli wrote:
> While we are on topic :) and as I finally understood what generational GC is[1], are there any fundamental issues with D to not use one?

I implemented one a long time ago. The only way to get write barriers with D is memory protection. It worked, but unfortunately the write barriers caused a severe performance penalty. It's possible that it might be viable with more tweaking, or in certain applications where most of the heap is not written to; I did not experiment a lot with it.

On Monday, 9 May 2022 at 00:25:43 UTC, H. S. Teoh wrote:
> In the past, the argument was that write barriers represented an unacceptable performance hit to D code.  But I don't think this has ever actually been measured. (Or has it?)  Maybe somebody should make a dmd fork that introduces write barriers, plus a generational GC (even if it's a toy, proof-of-concept-only implementation) to see if the performance hit is really as bad as believed to be.

Implementing write barriers in the compiler (by instrumenting code) means that you're no longer allowed to copy pointers to managed memory in non-D code. This is a stricter assumption that the current ones we have; for instance, copying a struct (which has indirections) with memcpy would be forbidden.

On Mon, May 09, 2022 at 05:52:30AM +0000, Vladimir Panteleev via Digitalmars-d-announce wrote:
> On Sunday, 8 May 2022 at 23:44:42 UTC, Ali Çehreli wrote:
> > While we are on topic :) and as I finally understood what generational GC is[1], are there any fundamental issues with D to not use one?
> 
> I implemented one a long time ago. The only way to get write barriers with D is memory protection. It worked, but unfortunately the write barriers caused a severe performance penalty.

Why is memory protection the only way to implement write barriers in D?


> It's possible that it might be viable with more tweaking, or in certain applications where most of the heap is not written to; I did not experiment a lot with it.

Interesting data point, in any case.


T

-- 
The early bird gets the worm. Moral: ewww...

On Mon, May 09, 2022 at 05:55:39AM +0000, Vladimir Panteleev via Digitalmars-d-announce wrote:
> On Monday, 9 May 2022 at 00:25:43 UTC, H. S. Teoh wrote:
> > In the past, the argument was that write barriers represented an unacceptable performance hit to D code.  But I don't think this has ever actually been measured. (Or has it?)  Maybe somebody should make a dmd fork that introduces write barriers, plus a generational GC (even if it's a toy, proof-of-concept-only implementation) to see if the performance hit is really as bad as believed to be.
> 
> Implementing write barriers in the compiler (by instrumenting code) means that you're no longer allowed to copy pointers to managed memory in non-D code. This is a stricter assumption that the current ones we have; for instance, copying a struct (which has indirections) with memcpy would be forbidden.

Hmm, true.  That puts a big damper on the possibilities... OTOH, if this could be made an optional feature, then code that we know doesn't need, e.g., passing pointers to C code, can take advantage of possibly better GC strategies.


T

-- 
English has the lovely word "defenestrate", meaning "to execute by throwing someone out a window", or more recently "to remove Windows from a computer and replace it with something useful". :-) -- John Cowan

On Monday, 9 May 2022 at 16:37:15 UTC, H. S. Teoh wrote:
> Why is memory protection the only way to implement write barriers in D?

Well, it's the only way I know of without making it a major backwards-incompatible change. The main restriction in this area is that it must continue working with code written in other languages, and generally not affect the ABI drastically.

On Mon, May 09, 2022 at 04:48:11PM +0000, Vladimir Panteleev via Digitalmars-d-announce wrote:
> On Monday, 9 May 2022 at 16:37:15 UTC, H. S. Teoh wrote:
> > Why is memory protection the only way to implement write barriers in D?
> 
> Well, it's the only way I know of without making it a major backwards-incompatible change. The main restriction in this area is that it must continue working with code written in other languages, and generally not affect the ABI drastically.

Ah, gotcha.  Yeah, I don't think such an approach would be fruitful (it was worth a shot, though!).  If D were ever to get write barriers, they'd have to be in some other form, probably more intrusive in terms of backwards-compatibility and ABI.


T

-- 
Curiosity kills the cat. Moral: don't be the cat.