O(N) Garbage collection?

[dsimcha]

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