On 11/23/17 13:40, Ola Fosheim Grøstad wrote:
On Thursday, 23 November 2017 at 20:13:31 UTC, Adam Wilson wrote:
I would focus on a generational GC first for two reasons. The
But generational GC only makes sense if many of your GC objects have a
short life span. I don't think this fits well with sensible use of a
language like D where you typically would try to put such allocations on
the stack and/or use RAII or even an arena.
Sensible to whom? The great thing about D is that it works just we well
for low-level people who need to wring the most out of the metal, AND
the high-level productivity minded apps people, who don't.
RAII+stack allocations make sense when I care about WHEN an object is
released and wish to provide some semblance of control over deallocation
(although as Andrei has pointed out numerous time, you have no idea how
many objects are hiding under that RAII pointer). But there are plenty
of use cases where I really don't care when memory is released, or even
how long it takes to release.
For example, all of the D apps that I've written and use in production,
GC-allocate everything. I don't have a single struct in the code. But I
don't care, because the program is so short lived and the working set so
small that there will never be GC collection. And it's not like this is
an uncommon or unwise pattern in D, DMD itself follows this exact
pattern. Obviously my pattern isn't "wrong" or else DMD itself is
"wrong". It's just not your definition of "correct".
Another use case where RAII makes no sense is GUI apps. The object graph
required to maintain the state of all those widgets can be an absolute
performance nightmare on destruction. Closing a window can result in the
destruction of tens-of-thousands of objects (I've worked on codebases
like that), all from the GUI thread, causing a hang, and a bad user
experience. Or you could use a concurrent GC and pass off the collection
to a different thread. (See .NET)
The second is that you still typically have to stop the execution of
the thread on the Gen0 collection (the objects most likely to be hot).
So with a non-generational concurrent collector you have to stop the
thread for the entirety of the scan, because you have no way to know
which objects are hot and which are cold.
How are you going to prove that references are all kept within the
generation in D? There is some very costly book keeping involved that
simply don't work well with D semantics.
Again, which semantics? If you compile with -betterc, the bookkeeping
and it's overhead simply don't exist.
Your arguments are based on a presupposition that D should only be used
a certain way; a way that, I am sure, mirrors your own usage patterns. D
supports a multitude of different usage patterns, some of which look
nothing like what you are holding up as "correct". And this is what
makes D special. To remove or dismiss as invalid those usage patterns
would be detrimental to those of us who use them and be catastrophic to
D in general.
As a community, can we please stop it with the subjective judgements of
what is and is not "sensible" in D, and start supporting the people
using it, however they are using it, even if we are sure that they are
"wrong"?
--
Adam Wilson
IRC: LightBender
import quiet.dlang.dev;
