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
