== Quote from Vladimir Panteleev ([email protected])'s article > P.S. I'm currently in the process of tracking down a memory corruption > bug, which *might* result in a GC patch for D1. I'm also instinctively > worried that touching the GC code may introduce new memory corruption > bugs, which can be EXTREMELY hard to find. I've been chasing this one for > 4 years.
I doubt it's a GC bug. If it's not a bug in your code, I'd be more inclined to assume it's a codegen bug, simply because the codegen is much larger and more complex, and there are more opportunities for weird bugs that can only be reproduced under very specific circumstances to creep in. Once you get past the superficial cruftiness and unreadability of the codebase and get a good conceptual model of it, D's GC is actually pretty simple. Also, I've been testing my patches by using the Phobos, std.parallelism/parallelfuture, and dstats unittests, and by simply eating my own dogfood (i.e. using my modified GC's when running some simulations and stuff). So far, so good. Unfortunately, we don't have a specific GC test suite, but IMHO if it works on this much real-world code, it's unlikely that I've created any bugs.
