You may be right, but:
1. Reinventing the wheel has its advantages in that you get to step
back and reevaluate things and remove all the cruft that built up on the
existing wheel.
2. I'm guessing this is a silly bug somewhere rather than a deep design
flaw, and that it can easily be solved by someone with a good mental
model of the whole implementation of the D GC (Sean or Walter) by using
a better data structure. I've found several things in the GC source
code that look like linear searches, but I don't understand the code
well enough to know what to do about them.
On 2/19/2011 10:17 AM, bearophile wrote:
dsimcha:
BTW, here are the timings if I remove the GC.BlkAttr.NO_SCAN, meaning
that everything gets scanned. Said timings aren't drastically
different. Something is seriously wrong here.
Languages like Clojure, Scala, Boo, etc, start their development on a virtual
machine where there is a refined GC, a standard library, a good back-end, etc,
all things that require a very large amount of work to be built well and tuned.
D language tries to re-create everything, even refusing the LLVM back-end (LDC
docet) so there is a lot of painful work to do, to create a decent enough GC,
etc. The current engineering quality of the Java GC will be out of reach of D
language maybe forever...
Bye,
bearophile
