| |
 | Posted by H. S. Teoh in reply to rikki cattermole | Permalink Reply |
|
H. S. Teoh 
Posted in reply to rikki cattermole
| 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
|