Civility

[H. S. Teoh]

On Sat, Jun 25, 2022 at 07:57:03AM +1200, rikki cattermole via Digitalmars-d wrote:
> 
> On 25/06/2022 7:51 AM, Walter Bright wrote:
> > Honesty - Since Java is heavily dependent on the gc, it is worth it
> > to insert write gates into the generated code to accurately track
> > usage of gc allocated memory. Usage of D's gc is optional, and D's
> > semantics are much less reliant on the gc. Hence, in the interest of
> > maximum performance for most code, D does not insert write gates in
> > the generated code.
> 
> Unfortunately pretty much all the advanced GC's require write
> barriers.
> 
> We are almost maxed out on what we can do.
> 
> At some point its going to have to be implemented as opt-in if we want
> to allow people to experiment with them.

Experimenting with advanced GCs is definitely something worth exploring
IMO.

Memory-related bugs are a constant scourge in code with manual memory
management.  Random example: this week I just got another chromium
update from my distro, fixing a bunch of issues. 4/9 issues were
use-after-free bugs. Out of curiosity, I did a little investigation to
get an idea of just how prevalent use-after-free bugs are. Here's a
brief run-down:

- 21 Jun 2022: 4 use-after-free bugs.
- 10 Jun 2022: 2 use-after-free bugs.
- 25 May 2022: 12 use-after-free bugs.
- 10 May 2022: 7 use-after-free bugs.
- 26 Apr 2022: 11 use-after-free bugs.
- 11 Apr 2022: 6 use-after-free bugs.
- 1 Apr 2022: 9 use-after-free bugs.
- 16 Mar 2022: 9 use-after-free bugs.
- 2 Mar 2022: 8 use-after-free bugs.
- 15 Feb 2022: 6 use-after-free bugs.
- 5 Feb 2022: 11 use-after-free bugs.
- 19 Jan 2022: 12 use-after-free bugs.

In total, there were a whopping 97 use-after-free bugs from the
beginning of the year until now.  And this is just *one* of numerous
memory-related bugs, in *one* piece of software. A disproportionately
large number of bugs per update are memory-related problems, such as
use-after-free, out-of-bounds memory access, heap buffer overflow, etc..
And mind you, these are only the bugs that were *discovered* and
reported. I suspect a fair number of them lie latent, either
undiscovered or discovered but unreported by unscrupulous parties.

Manual memory management may have its place, perhaps in low-level code
in the kernel or something, but in application code it's just a constant
source of bugs and a non-stop drain on resources to find and fix said
bugs.  It's time the world moved on to GC'd languages. And for that, D
needs a competitive GC.  If write barriers are what it takes to get one,
then it's well worth the effort IMO.


T

-- 
If you look at a thing nine hundred and ninety-nine times, you are perfectly safe; if you look at it the thousandth time, you are in frightful danger of seeing it for the first time. -- G. K. Chesterton