Release: serverino - please destroy it.

[H. S. Teoh]

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